Re: numeric_to_number() function skipping some digits

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