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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "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-30 23:26:55
Message-ID: 943476.1601508415@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 Wed, Sep 30, 2020 at 06:10:38PM -0400, Robert Haas wrote:
>> On Wed, Sep 30, 2020 at 5:35 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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, or a cache lookup failure,
>> so fixing those things can only help people. But there is no reason at
>> all why someone shouldn't be relying on this very old and
>> long-established behavior not to change in a minor release.

> That is an interesting distinction.

I don't want to sound like I'm totally without sympathy for Robert's
argument. But I do say it's a judgment call, and my judgment remains
that this patch is appropriate to back-patch.

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 such updates
breaking applications that expected the meaning of, say,
'2022-04-01 12:34 Europe/Paris' to hold still. But we do it
anyway.

As another not-too-old example, I'll cite Robert's own commits
0278d3f79/a08bfe742. The argument for a back-patch there was
pretty much only that we were writing an alleged tar file that
didn't conform to the letter of the POSIX spec. It's possible
to imagine that somebody had written bespoke archive-reading
code that failed after we changed the output; but that didn't
seem probable enough to justify continuing to violate the standard.

In this case the "standard" in question is the Oracle-derived
expectation that to_date will read negative years as BC, and
I'd argue that the possibility that someone already has code
that relies on getting an off-by-one result is outweighed by the
likelihood that the misbehavior will hurt somebody in the future.

This calculus would obviously change if we knew of such code
or thought it was really probable for it to exist. That's
what makes it a judgment call.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2020-09-30 23:41:47 Re: BUG #16419: wrong parsing BC year in to_date() function
Previous Message Bruce Momjian 2020-09-30 22:36:56 Re: BUG #16419: wrong parsing BC year in to_date() function

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2020-09-30 23:41:47 Re: BUG #16419: wrong parsing BC year in to_date() function
Previous Message Andres Freund 2020-09-30 22:43:17 Re: Improving connection scalability: GetSnapshotData()