From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #16419: wrong parsing BC year in to_date() function |
Date: | 2020-09-29 17:26:29 |
Message-ID: | 663099.1601400389@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Bruce Momjian <bruce(at)momjian(dot)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 we need to apply the patches to all branches at the same time.
> I am not sure we want to document a behavior we know will change in PG
> 14.
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2020-09-29 17:31:48 | BUG #16642: INFORMATION_SCHEMA-DESIGN |
Previous Message | Tom Lane | 2020-09-29 16:38:52 | Re: BUG #16622: pg_dump produces erroneus ALTER TABLE statement for a table with an inherited generated column |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2020-09-29 17:50:07 | Re: BUG #16419: wrong parsing BC year in to_date() function |
Previous Message | Tom Lane | 2020-09-29 16:46:46 | Re: Dumping/restoring fails on inherited generated column |