On Wed, Sep 30, 2020 at 02:11:54PM -0400, Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > On Tue, Sep 29, 2020 at 01:26:29PM -0400, Tom Lane wrote: > >> Bruce Momjian <br...@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.
Yes, I was thinking just the major release notes. What are you suggesting, and what did you ultimately decide to do? What I didn't want to do was to document the old behavior in the old docs and change it in PG 14. -- Bruce Momjian <br...@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
