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

On Wed, Sep 30, 2020 at 7:26 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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