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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: BUG #16419: wrong parsing BC year in to_date() function
Дата
Msg-id CA+TgmoaZ9w=WwmE3xRUCN0bSzYp14kU6_MAy-wJUpgpDmVMYpA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #16419: wrong parsing BC year in to_date() function  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #16419: wrong parsing BC year in to_date() function  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: BUG #16419: wrong parsing BC year in to_date() function  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
On Wed, Sep 30, 2020 at 5:35 PM Tom Lane <tgl@sss.pgh.pa.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #16419: wrong parsing BC year in to_date() function
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Error on failed COMMIT