Re: BUG #16419: wrong parsing BC year in to_date() function - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: BUG #16419: wrong parsing BC year in to_date() function
Date
Msg-id CAKFQuwZV0UxbyYTxuJhf1j1X=3HG5QA6qtEp+C+=LzOFtNEt3A@mail.gmail.com
Whole thread Raw
In response to Re: BUG #16419: wrong parsing BC year in to_date() function  (Bruce Momjian <bruce@momjian.us>)
Responses Re: BUG #16419: wrong parsing BC year in to_date() function  (Bruce Momjian <bruce@momjian.us>)
Re: BUG #16419: wrong parsing BC year in to_date() function  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On Thu, Sep 3, 2020 at 6:21 PM Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Jul 15, 2020 at 09:26:53AM -0700, David G. Johnston wrote:

> 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.

I agree that someone else should write another patch to fix the behavior for v14.  Still suggest committing the proposed patch to master and all supported versions to document the existing behavior correctly.  The fix patch can work from that.

David J.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Questionable ping logic in LogicalRepApplyLoop
Next
From: Juan José Santamaría Flecha
Date:
Subject: Re: A micro-optimisation for walkdir()