Robert Haas <robertmhaas@gmail.com> writes:
> 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.
Good, so at least we agree on that principle.
> 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.
Sure, we have at least two bug reports proving that people have
investigated this. What I'm saying is unlikely is that there are any
production applications in which it matters. I doubt that, say, the
Italian government has a citizenry database in which they've recorded
Julius Caesar's birthday; and even if they do, they're probably not
squirting the data through to_date; and even if they are, they're more
likely using the positive-year-with-BC representation, because that's
the only one that PG will emit. Even if they've got code that somehow
relies on to_date working this way, it's almost certainly getting zero
use in practice.
I probably wouldn't have taken an interest in this at all, were it
not for the proposal that we document the misbehavior. Doing that
rather than fixing it just seems silly.
regards, tom lane