Автопередача от VARCHAR «ГГГГ-ММ» на сегодняшний день в PostgreSQL

Question

У меня есть столбец типа date, где используются только год и месяц. Я хотел бы использовать сокращенный формат даты в запросах SQL, например:

SELECT * FROM my_table where date_column='2019-10';

Конечно, теперь это приводит к ошибке:

SQL Error [22007]: ERROR: invalid input syntax for type date: "2019-12"

Есть ли шанс сделать это возможным? Спасибо!

---

Редактировать:

Чего я хочу добиться, так это сделать его автоматическим. Я знаю, что могу привести свою строку к дате to_date('2019-10','YYYY-MM'). Мой вопрос заключается в том, как сделать так, чтобы мой запрос выглядел так: SELECT * FROM my_table where date_column='2019-10'. Без каких-либо кастинга и конвертации.

Я читаю о CREATE CAST заявлении, но я не уверен, что это то, что я ищу здесь.

Answer 1

Я бы порекомендовал:

where date_column >= ('2019-10' || '-01')::date and
      date_column < ('2019-10' || '-01')::date + interval '1 month'

Эта формулировка позволяет использовать индекс для date_column для запроса, если такой индекс доступен.

Если вы этого не сделаетепозаботьтесь об этом, вы можете использовать to_char():

where to_char(date_column, 'YYYY-MM') = '2019-10'

Answer 2

Один из способов - проверить YEAR и MONTH отдельно:

SELECT * 
FROM my_table 
WHERE EXTRACT(YEAR FROM date_column) = 2019
AND EXTRACT(MONTH FROM date_column) = 10

SQL Fiddle

Answer 3

Попробуйте это:

SELECT
    * 
FROM
    my_table 
WHERE
    DATE_PART('YEAR',CURRENT_DATE)='2019' AND
    DATE_PART('MONTH',CURRENT_DATE)='10';

Answer 4

Отличный вариант, который большинство людей забывают, - оставить столбец character(7) и вставить его, как вы это сделали сейчас. Сравнение строк с использованием = < <= > >= будет работать правильно, если вы придерживаетесь формата ISO-8601, как в приведенном вами примере, то есть YYYY-MM. Вам на самом деле не нужно использовать формат даты.

Это, однако, предполагает, что вы проверяете действительность в приложении, что будет лучшим способом избежать проблем с часовым поясом, с которыми вы столкнетесь приболее простое решение проверки по current_date в базе данных. Это раннее предупреждение для вас, поскольку вы не будете знать, что у вас есть проблема с часовым поясом, пока клиенты не пожалуются, что их платеж не был обработан.