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

Robert Haas writes: > Right. Ultimately, this comes down to a judgement call about what you > think people are likely to rely on, and what you think they are > unlikely to rely on. Good, so at least we agree on that principle. > But the present case does not seem to me to be comparable. If

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

On Wed, Sep 30, 2020 at 5:24 PM Robert Haas wrote: > The > fact that we've suddenly discovered that this is not what Oracle does > doesn't mean that no users have discovered that it is what PostgreSQL > does. > Presently I cannot seem to make up my mind so I'm going to go with my original

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

On Wed, Sep 30, 2020 at 7:26 PM Tom Lane wrote: > We do not have, and never have had, a project policy against > back-patching non-crash-related behavioral changes. If we did, > we would not for example put timezone database updates into the > back branches. It's not terribly hard to imagine

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

On Wed, Sep 30, 2020 at 07:26:55PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Wed, Sep 30, 2020 at 06:10:38PM -0400, Robert Haas wrote: > >> On Wed, Sep 30, 2020 at 5:35 PM Tom Lane wrote: > >>> By that logic, we should never fix any bug in a back branch. > > >> No, by that logic, we

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

Bruce Momjian writes: > On Wed, Sep 30, 2020 at 06:10:38PM -0400, Robert Haas wrote: >> On Wed, Sep 30, 2020 at 5:35 PM Tom Lane wrote: >>> By that logic, we should never fix any bug in a back branch. >> No, by that logic, we should not change any behavior in a back-branch >> upon which a

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

On Wed, Sep 30, 2020 at 06:10:38PM -0400, Robert Haas wrote: > On Wed, Sep 30, 2020 at 5:35 PM Tom Lane wrote: > > By that logic, we should never fix any bug in a back branch. > > No, by that logic, we should not change any behavior in a back-branch > upon which a customer is plausibly relying.

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

Robert Haas writes: > On Wed, Sep 30, 2020 at 5:35 PM Tom Lane wrote: >> By that logic, we should never fix any bug in a back branch. > No, by that logic, we should not change any behavior in a back-branch > upon which a customer is plausibly relying. I guess where we differ here is on the

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

On Wed, Sep 30, 2020 at 5:35 PM Tom Lane wrote: > By that logic, we should never fix any bug in a back branch. No, by that logic, we should not change any behavior in a back-branch upon which a customer is plausibly relying. No one relies on a certain query causing a server crash, for example,

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

Robert Haas writes: > On Tue, Sep 29, 2020 at 1:26 PM Tom Lane wrote: >> 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

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

On Tue, Sep 29, 2020 at 1:26 PM Tom Lane wrote: > 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

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

On Wed, Sep 30, 2020 at 03:11:06PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Wed, Sep 30, 2020 at 02:50:31PM -0400, Tom Lane wrote: > >> Actually, I was just finishing up back-patching the patch I posted > >> yesterday. I think we should just fix it, not document that it's > >>

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

Bruce Momjian writes: > On Wed, Sep 30, 2020 at 02:50:31PM -0400, Tom Lane wrote: >> Actually, I was just finishing up back-patching the patch I posted >> yesterday. I think we should just fix it, not document that it's >> broken. > Agreed, that's what I wanted. You stated in a later email you

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

On Wed, Sep 30, 2020 at 02:50:31PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Wed, Sep 30, 2020 at 02:11:54PM -0400, Tom Lane wrote: > >> 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 > >>

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

Bruce Momjian writes: > On Wed, Sep 30, 2020 at 02:11:54PM -0400, Tom Lane wrote: >> 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,

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

On Wed, Sep 30, 2020 at 02:11:54PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > On Tue, Sep 29, 2020 at 01:26:29PM -0400, Tom Lane wrote: > >> Bruce Momjian writes: > >>> On Fri, Sep 4, 2020 at 12:45:36PM -0700, David G. Johnston wrote: > Because we already have the to_date/make_date

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

Bruce Momjian writes: > On Tue, Sep 29, 2020 at 01:26:29PM -0400, Tom Lane wrote: >> Bruce Momjian 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

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

On Tue, Sep 29, 2020 at 01:26:29PM -0400, Tom Lane wrote: > Bruce Momjian 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

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

I wrote: > 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 >

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

Peter Eisentraut writes: > Adding support for negative years in make_timestamp seems pretty > straightforward; see attached patch. In hopes of moving things along, I pushed that, along with documentation additions. I couldn't quite convince myself that it was a bug fix though, so no

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

Bruce Momjian 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

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

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:not tested Patch looks good to me. The new status of this patch is: Ready

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

On 2020-09-04 21:45, David G. Johnston wrote: On Thu, Sep 3, 2020 at 6:21 PM Bruce Momjian > 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 >

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

On Fri, Sep 4, 2020 at 12:45:36PM -0700, David G. Johnston wrote: > On Thu, Sep 3, 2020 at 6:21 PM Bruce Momjian 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 >

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

On Thu, Sep 3, 2020 at 6:21 PM Bruce Momjian 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

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

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

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

On Tue, May 12, 2020 at 8:56 PM Laurenz Albe 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

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

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

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

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. David J. On Wed, May 6, 2020 at 8:12 PM David G.