On Wed, Jul 15, 2020 at 09:26:53AM -0700, David G. Johnston wrote: > On Tue, May 12, 2020 at 8:56 PM Laurenz Albe <laurenz.a...@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.
OK, so, looking at this thread, we have to_date() treating -1 as -2 BC, make_date() treating -1 as 1 BC, and we have Oracle, which to_date() is supposed to match, making -1 as 1 BC. Because we already have the to_date/make_date inconsistency, and the -1 to -2 BC mapping is confusing, and doesn't match Oracle, I think the clean solution is to change PG 14 to treat -1 as 1 BC, and document the incompatibility in the release notes. -- Bruce Momjian <br...@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee