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

From: Brendan Jurd <direvus(at)gmail(dot)com>
To: Jeremy Ford <jeremford(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 09:38:26
Message-ID: 37ed240d0906240238n43e84b4du2f686bc6d2947b6b@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

2009/6/24 Jeremy Ford <jeremford(at)gmail(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Richard Tector 2009-06-24 10:21:13 BUG #4877: LDAP auth allows empty password string
Previous Message Bhushan Verma 2009-06-24 09:30:00 Re: psql: FATAL: the database system is in recovery mode

Browse pgsql-hackers by date

  From Date Subject
Next Message Boszormenyi Zoltan 2009-06-24 09:51:57 ECPG dynamic cursor, SQLDA support
Previous Message Dimitri Fontaine 2009-06-24 07:59:28 Re: Extensions User Design