On Wed, Sep 30, 2020 at 7:26 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > We do not have, and never have had, a project policy against > back-patching non-crash-related behavioral changes. If we did, > we would not for example put timezone database updates into the > back branches. It's not terribly hard to imagine such updates > breaking applications that expected the meaning of, say, > '2022-04-01 12:34 Europe/Paris' to hold still. But we do it > anyway. > > As another not-too-old example, I'll cite Robert's own commits > 0278d3f79/a08bfe742. The argument for a back-patch there was > pretty much only that we were writing an alleged tar file that > didn't conform to the letter of the POSIX spec. It's possible > to imagine that somebody had written bespoke archive-reading > code that failed after we changed the output; but that didn't > seem probable enough to justify continuing to violate the standard.
Right. Ultimately, this comes down to a judgement call about what you think people are likely to rely on, and what you think they are unlikely to rely on. If I recall correctly, I thought that case was a close call, and back-patched because you argued for it. Either way, it does seem very unlikely that someone would write archive-reading code that relies on the presence of an extra 511 zero bytes, because (1) it would be a lot easier to just use 'tar', (2) such code would fail if used with a tar archive generated by anything other than PostgreSQL, and (3) such code would fail on a tar archive generated by PostgreSQL but without using -R. It is just barely plausible that someone has a version of 'tar' that fails on the bogus archive and will work with that fix, though I would guess that's also pretty unlikely. But the present case does not seem to me to be comparable. If someone is using to_date() to construct date values, I can't see why they wouldn't test it, find out how it works with BC values, and then make the application that generates the input to that function do the right thing for the actual behavior of the function. There are discussions of the behavior of to_date with YYYY = 0 going back at least 10 years on this mailing list, and more recent discussions of the behavior of negative numbers. Point being: I knew about the behavior that was here reported as a bug and have known about it for years, and if I were still an application developer I can easily imagine having coded to it. I don't know why someone else should not have done the same. The fact that we've suddenly discovered that this is not what Oracle does doesn't mean that no users have discovered that it is what PostgreSQL does. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
