Функция PostgreSQL to_char() работает не так, как ожидалось

#sql #postgresql #join #to-char

Вопрос:

Это моя схема ниже введите описание изображения здесь

И я должен решить этот вопрос: «Как вы можете составить список времени начала бронирования теннисных кортов на дату «2012-09-21″? Верните список пар времени начала и названия объекта, упорядоченных по времени.»

Запрос ниже работает нормально

 select bks.starttime as start, facs.name as name
from 
    cd.facilities facs
    inner join cd.bookings bks
        on facs.facid = bks.facid
where 
    facs.name in ('Tennis Court 2','Tennis Court 1') and
    bks.starttime >= '2012-09-21' and
    bks.starttime < '2012-09-22'
order by bks.starttime
 

Но этот запрос ниже с помощью to_char() не работает. В чем здесь проблема?

  select starttime,name 
 from cd.bookings, cd.facilities 
     where cd.bookings.facid = cd.facilities.facid 
     and cd.facilities.name like 'Tennis Court%' 
     and to_char(cd.bookings.starttime,'YYYY-MM-DD') = '2012-09-21'
 order by cd.bookings.starttime
 

Я выполняю это упражнение на этом URL-адресе: https://pgexercises.com/questions/joins/simplejoin2.html

Комментарии:

1. Пожалуйста, определите «не работает». Что именно происходит, когда вы используете второй запрос. Но первый запрос — лучший способ сделать это. В качестве альтернативы, возможно starttime::date = date '2012-09-21' (но это не будет использовать индекс на starttime )

2. Одно очевидное отличие состоит в том, что второй запрос вернет все «теннисные корты», в то время как первый вернет только корты 1 и 2

3. @a_horse_with_no_name Спасибо тебе. Теперь он работает после перезагрузки вкладки браузера. Запрос был правильным. Но я хочу знать, почему первый запрос является лучшим способом сделать это вместо второго запроса?. Не могли бы вы, пожалуйста, дать мне подсказку или объяснить это.

4. Это немного субъективно, но: для одного явное JOIN должно быть предпочтительнее устаревших неявных условий соединения в предложении WHERE. Первый запрос также лучше, потому что он может использовать индекс starttime для ускорения поиска данных, в то время как для второго (или использования starttime::date = ... ) потребуется дополнительный специальный индекс, который, вероятно, полезен только для этого запроса и ничего больше