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

From: Jeremy Ford <jeremford(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Brendan Jurd <direvus(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: BUG #4862: different results in to_date() between 8.3.7 & 8.4.RC1
Date: 2009-06-24 05:08:25
Message-ID: 9b8ea02b0906232208n2bf81918ob3530a7c2ae04a5f@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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)

The others in that set of queries all work as expected ("2009-03-01"):
SELECT to_date(' 2009 03', 'YYYYMM') as nospace; --returns "2009-03-01"
SELECT to_date(' 2009 03', 'YYYY MM') as monthspace; --returns "2009-03-01"
SELECT to_date(' 2009 03', ' YYYY MM') as bothspaces; --returns "2009-03-01"

cheers, jeremy.

On Tue, Jun 23, 2009 at 3:55 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Brendan Jurd <direvus(at)gmail(dot)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
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Роман Галеев 2009-06-24 05:36:37 Re: BUG #4874: vacuum doest work
Previous Message Jim Michaels 2009-06-24 01:59:05 BUG #4876: author of MD5 says it's seriously broken - hash collision resistance problems

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-06-24 05:09:57 pg_listener attribute number #defines
Previous Message Jaime Casanova 2009-06-24 04:27:11 Re: Extensions User Design