Re: BUG #4862: different results in to_date() between 8.3.7 & 8.4.RC1

2009/6/23 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> I'm hesitant to fool with this post-RC, and we don't have "a couple of
> days" to wait for a fix --- 8.4.0 is scheduled to wrap on Thursday.
> However, I see that the first of these cases actually represents a
> regression from 8.3 and before; existing releases get 2009-03-01 out
> of it while 8.4 fails to.  So it seems we'd better do something.

Ugh, I just noticed that even something like the following will work in 8.3:

8.3=# select to_date(' 2009 03 01', 'YYYYMMDD');

So it's not as simple as just treating whitespace at the *beginning*
of the string specially. There's something else going on.

[after trawling in the 8.3 code]

I think I've found the regression. The 8.3 code was using sscanf to
harvest integers, and was then calling a local function strspace_len()
to skip over any whitespace immediately before the integer.

So, any whitespace preceding any integer field was being explicitly
bypassed inside the "no separator" code path. Although oddly it
doesn't bypass whitespace preceding *text* fields:

8.3=# select to_date('2009 Mar02', 'YYYYMonDD');
ERROR: invalid value for MON/Mon/mon

I should be able to get the same results by snipping an extra
strspace_len() characters in the new code path in
from_char_parse_int_len(). This ought to be a one-line fix that
doesn't clobber the good parts of my work so far. I'll run some tests
and then post a patch within the hour. Does that work for you?

Cheers,
BJ