Robert Haas <robertmh...@gmail.com> writes: > On Wed, Sep 30, 2020 at 5:35 PM Tom Lane <t...@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
