On Sat, Sep 19, 2009 at 1:52 AM, Brendan Jurd <direvus(at)gmail(dot)com> wrote:
> 2009/9/19 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> > Should we have it throw an error if the input corresponding to a G
> > symbol doesn't match the expected group separator? I'm concerned that
> > that would break applications that work okay today.
> It would be a substantial change to the behaviour, and to do it
> properly we'd have to change to_date() to actually parse separator
> characters as well.
> That is, you can currently write to_date('2009/09/19', 'YYYY-MM-DD')
> -- it doesn't matter what the separator characters actually look like,
> since per the format pattern they cannot affect the date outcome.
> This naturally leads to the question we always have to ask with these
> functions: What Does Oracle Do?
Oracle returns "19-SEP-09" irrespective of the format.
Here in PG, we have getting the proper date irrespective of the format as
Oracle. But in the case to to_number the returned value is wrong. For
example following query returns '340' on PG where as it returns '3450' on
select to_number('34,50','999,99') from dual;
> But FWIW, a -1 from me for changing this.
Do you mean this is the expected behaviour then?
Jeevan B Chalke
EnterpriseDB Software India Private Limited, Pune
Visit us at: www.enterprisedb.com
If better is possible, then good is not enough
In response to
pgsql-hackers by date
|Next:||From: Jaime Casanova||Date: 2009-09-21 06:32:40|
|Subject: Re: [PATCH] Largeobject access controls|
|Previous:||From: Alvaro Herrera||Date: 2009-09-21 04:21:43|
|Subject: Re: TODO item: Allow more complex user/database default