Horton

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

David G. Johnston <david.g.johnston@gmail.com>

View thread View on postgr.es
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-07-15T16:26:53Z
Lists: pgsql-bugs, pgsql-hackers

Attachments

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.

Commits

  1. Fix handling of BC years in to_date/to_timestamp.

  2. Fix make_timestamp[tz] to accept negative years as meaning BC.

  3. doc: PG 13 relnotes, update TOAST item to mention decompression