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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, "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 22:10:38
Message-ID: CA+TgmoaZ9w=WwmE3xRUCN0bSzYp14kU6_MAy-wJUpgpDmVMYpA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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.

One reason they might do that is because there was a discussion about
what I believe to this exact same case 4 years ago in which you and I
both endorsed the position you are now claiming is so unreasonable
that nobody will mind if we change it in a minor release.

https://www.postgresql.org/message-id/flat/CAKOSWNmwCH0wx6MApc1A8ww%2B%2BEQmG07AZ3t6w_XjRrV1xeZpTA%40mail.gmail.com

So you now think this should be back-patched when previously you
didn't even think it was be good enough for master.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2020-09-30 22:36:37 Re: BUG #16419: wrong parsing BC year in to_date() function
Previous Message Tom Lane 2020-09-30 21:52:38 Re: BUG #16643: PG13 - Logical replication - initial startup never finishes and gets stuck in startup loop

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2020-09-30 22:14:52 Re: Error on failed COMMIT
Previous Message Tom Lane 2020-09-30 21:35:43 Re: BUG #16419: wrong parsing BC year in to_date() function