Re: BUG #16419: wrong parsing BC year in to_date() function
От | Bruce Momjian |
---|---|
Тема | Re: BUG #16419: wrong parsing BC year in to_date() function |
Дата | |
Msg-id | 20200930234147.GI26841@momjian.us обсуждение исходный текст |
Ответ на | Re: BUG #16419: wrong parsing BC year in to_date() function (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, Sep 30, 2020 at 07:26:55PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.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@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. > > > 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. Agreed. I was just thinking it was an interesting classification that no one relies on crashes, or query failures. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
В списке pgsql-hackers по дате отправления: