Robert Haas <robertmhaas@gmail.com> writes:
> 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.
I guess where we differ here is on the idea that somebody is plausibly
relying on to_date() to parse a BC date inaccurately.
> 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
What I complained about in that thread was mainly that that
patch was simultaneously trying to get stricter (throw error for
year zero) and laxer (parse negative years as BC).
Also, we did not in that thread have the information that Oracle
treats negative years as BC. Now that we do, the situation is
different, and I'm willing to change my mind about it. Admittedly,
Oracle seems to require an "S" in the format to parse a leading
dash as meaning a negative year. But given that our code is willing
to read the case as a negative year without that, it seems pretty
silly to decide that it should read it as an off-by-one negative
year.
regards, tom lane
