Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Mar 17, 2011 at 9:46 AM, Alvaro Herrera
> <alvherre@commandprompt.com> wrote:
>> Keep in mind that the datetime stuff was abandoned by the maintainer
>> some years ago with quite some rough edges. �Some of it has been fixed,
>> but a lot of bugs remain. �Looks like this is one of those places and it
>> seems appropriate to spend some time fixing it. �Since it would involve
>> a behavior change, it should only go to 9.2, of course.
> I wouldn't object to fixing the problem with # of digits > # of Ys in
> 9.1, if the fix is simple and clear-cut. I think we are still
> accepting patches to make minor tweaks, like the tab-completion patch
> I committed yesterday. It also doesn't bother me tremendously if we
> push it off, but I don't think that anyone's going to be too sad if
> TO_DATE('01-jan-2010', 'DD-MON-YYY') starts returning something more
> sensible than 3010-01-01.
Agreed, it's certainly not too late for bug fixes in 9.1. I agree
that this isn't something we would want to tweak in released branches,
but 9.1 isn't there yet.
Having said that, it's not entirely clear to me what sane behavior is
here. Personally I would expect that an n-Ys format spec would consume
at most n digits from the input. Otherwise how are you going to use
to_date to pick apart strings that don't have any separators? So
I think the problem is actually upstream of the behavior complained of
here. However, what we should first do is see what Oracle does in such
cases, because the main driving factor for these functions is Oracle
compatibility not what might seem sane in a vacuum.
regards, tom lane
