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

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <bruce@momjian.us>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>, Laurenz Albe <laurenz.albe@cybertec.at>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-09-30T18:11:54Z
Lists: pgsql-bugs, pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> On Tue, Sep 29, 2020 at 01:26:29PM -0400, Tom Lane wrote:
>> Bruce Momjian <bruce@momjian.us> writes:
>>> On Fri, Sep  4, 2020 at 12:45:36PM -0700, David G. Johnston wrote:
>>>> 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.

>> I think this is nuts.  The current behavior is obviously broken;
>> we should just treat it as a bug and fix it, including back-patching.
>> I do not think there is a compatibility problem of any significance.
>> Who out there is going to have an application that is relying on the
>> ability to insert BC dates in this way?

> You are agreeing with what I am suggesting then?

Hm, I read your reference to "the release notes" as suggesting that
we should change it only in a major release, ie HEAD only (and it
looks like David read it the same).  If you meant minor release notes,
then we're on the same page.

			regards, tom lane



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