Re: numeric_to_number() function skipping some digits - Mailing list pgsql-hackers

From Brendan Jurd
Subject Re: numeric_to_number() function skipping some digits
Date
Msg-id 37ed240d0909210006x717969a5v7f74a753b94f9c8b@mail.gmail.com
Whole thread Raw
In response to Re: numeric_to_number() function skipping some digits  (Jeevan Chalke <jeevan.chalke@enterprisedb.com>)
Responses Re: numeric_to_number() function skipping some digits
Re: numeric_to_number() function skipping some digits
List pgsql-hackers
2009/9/21 Jeevan Chalke <jeevan.chalke@enterprisedb.com>:
> 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;
>

Hi Jeevan,

Thanks for checking up on the Oracle behaviour.  It appears to
silently disregard grouping characters in the format pattern, and also
disregard them wherever they appear in the input string (or else it
reads the string from right-to-left?).

It seems that, to match Oracle, we'd need to teach the code that 'G'
and ',' are no-ops for to_number(), and also that such characters
should be ignored in the input.

To be honest, though, I'm not sure it's worth pursuing.  If you want
to feed in numbers that have decorative characters all through them,
it's far more predictable to just regex out the cruft and use ordinary
numeric parsing than to use to_number(), which is infamous for its
idiosyncrasies:

# SELECT regexp_replace('34,50', E'[\\d.]', '', 'g')::numeric;
3450

Cheers,
BJ


pgsql-hackers by date:

Previous
From: Jeevan Chalke
Date:
Subject: Re: numeric_to_number() function skipping some digits
Next
From: Brendan Jurd
Date:
Subject: Re: numeric_to_number() function skipping some digits