Re: BUG #16419: wrong parsing BC year in to_date() function

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: BUG #16419: wrong parsing BC year in to_date() function
Дата
Msg-id CAKFQuwb_3yNTTE6cG_YtXFtV=CkQf0uMSMB0oxC1YNrF94pfuA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #16419: wrong parsing BC year in to_date() function  (Laurenz Albe <laurenz.albe@cybertec.at>)
Ответы Re: BUG #16419: wrong parsing BC year in to_date() function  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Tue, May 12, 2020 at 8:56 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Tue, 2020-05-12 at 18:09 -0700, David G. Johnston wrote:
> Redirecting to -hackers for visibility.  I feel there needs to be something done here, even if just documentation (a bullet in the usage notes section - and a code comment update for the macro)
> pointing this out and not changing any behavior.

Since "to_date" is an Oracle compatibility function, here is what Oracle 18.4 has to say to that:

SQL> SELECT to_date('0000', 'YYYY') FROM dual;
SELECT to_date('0000', 'YYYY') FROM dual
               *
ERROR at line 1:
ORA-01841: (full) year must be between -4713 and +9999, and not be 0


Attached is a concrete patch (back-patchable hopefully) documenting the current reality.

As noted in the patch commit message (commentary really):

make_timestamp not agreeing with make_date on how to handle negative years should probably just be fixed - but that is for someone else to handle.

Whether to actually change the behavior of to_date is up for debate though I would presume it would not be back-patched.

David J.
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Have SIGHUP instead of SIGTERM for config reload in logical replication launcher
Следующее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: Postgres is not able to handle more than 4k tables!?