Обсуждение: Re: [BUGS] BUG #4862: different results in to_date() between 8.3.7 & 8.4.RC1

2009/6/23 Tom Lane <tgl@sss.pgh.pa.us>:
> Brendan Jurd <direvus@gmail.com> writes:
>> 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?
>
> +1
>

[cross-posting to -hackers]

Here's a one-line patch to fix a regression in the new from_char code
I introduced into 8.4.

Versions <= 8.3 skipped over any whitespace immediately preceding any
integer field, and this behaviour was lost in HEAD when my from_char
patch was committed back in September '08 [1].

Fortunately, since the code has been refactored, this now only needs
to be repaired in one place =)

With thanks to Jeremy Ford for sending in his bug report, and an
abject mea culpa.

Cheers,
BJ

[1] http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=6f09ab2c24491a217f8b88012aababf3b723b902

Brendan Jurd <direvus@gmail.com> writes:
> Here's a one-line patch to fix a regression in the new from_char code
> I introduced into 8.4.

> Versions <= 8.3 skipped over any whitespace immediately preceding any
> integer field, and this behaviour was lost in HEAD when my from_char
> patch was committed back in September '08 [1].

Applied along with some regression test additions.  Thanks for the
quick response.
        regards, tom lane

2009/6/24 Jeremy Ford <jeremford@gmail.com>:
> I've just compiled and run the 8.4.RC2 code. For both of the following
> queries I get "0009-03-01"
>
> SELECT to_date(' 2009 03', '  YYYY MM') as extraspace; --returns
> "0009-03-01"
> SELECT to_date('2009 03', ' YYYY MM') as bogusspace; --returns "0009-03-01"
>
> Was it the intention to imitate Oracle behavior for these two cases in this
> release? (8.3.7 returns "0009-03-01" as well)

I think, at this stage (so close to release) we're just trying to keep
up a reasonable compatibility with 8.3 and earlier.  The fact that the
"bogus space" case doesn't match the Oracle behaviour might be fertile
ground for future improvement in the 8.5 cycle.

Thanks for testing!

Cheers,
BJ

I've just compiled and run the 8.4.RC2 code. For both of the following queries I get "0009-03-01"<br /><br /> SELECT
to_date('2009 03', '  YYYY MM') as extraspace; --returns "0009-03-01"<br /> SELECT to_date('2009 03', ' YYYY MM') as
bogusspace;--returns "0009-03-01"<br /><br /> Was it the intention to imitate Oracle behavior for these two cases in
thisrelease? (8.3.7 returns "0009-03-01" as well)<br /><br /> The others in that set of queries all work as expected
("2009-03-01"):<br/> SELECT to_date(' 2009 03', 'YYYYMM') as nospace; --returns "2009-03-01"<br /> SELECT to_date('
200903', 'YYYY MM') as monthspace; --returns "2009-03-01"<br /> SELECT to_date(' 2009 03', ' YYYY MM') as bothspaces;
--returns"2009-03-01"<br /><br />cheers, jeremy.<br /><br /><div class="gmail_quote">On Tue, Jun 23, 2009 at 3:55 AM,
TomLane <span dir="ltr"><<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>></span> wrote:<br /><blockquote
class="gmail_quote"style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
1ex;"><divclass="im">Brendan Jurd <<a href="mailto:direvus@gmail.com">direvus@gmail.com</a>> writes:<br
/></div><divclass="im">> Here's a one-line patch to fix a regression in the new from_char code<br /> > I
introducedinto 8.4.<br /><br /> > Versions <= 8.3 skipped over any whitespace immediately preceding any<br />
>integer field, and this behaviour was lost in HEAD when my from_char<br /> > patch was committed back in
September'08 [1].<br /><br /></div>Applied along with some regression test additions.  Thanks for the<br /> quick
response.<br/><br />                        regards, tom lane<br /></blockquote></div><br />