Skip site navigation (1) Skip section navigation (2)

Re: numeric_to_number() function skipping some digits

From: Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>
To: Brendan Jurd <direvus(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: numeric_to_number() function skipping some digits
Date: 2009-09-21 06:10:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

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?

> Cheers,
> BJ

Jeevan B Chalke
EnterpriseDB Software India Private Limited, Pune
Visit us at:
If better is possible, then good is not enough

In response to


pgsql-hackers by date

Next:From: Jaime CasanovaDate: 2009-09-21 06:32:40
Subject: Re: [PATCH] Largeobject access controls
Previous:From: Alvaro HerreraDate: 2009-09-21 04:21:43
Subject: Re: TODO item: Allow more complex user/database default GUC settings

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group