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: be46a4f30909202310k1cf7dde2n8ac49319d570fff@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Hi,

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
Oracle.

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: www.enterprisedb.com
---
If better is possible, then good is not enough

In response to

Responses

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-2014 The PostgreSQL Global Development Group