Re: numeric_to_number() function skipping some digits

From: Brendan Jurd <direvus(at)gmail(dot)com>
To: Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(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 07:06:06
Message-ID: 37ed240d0909210006x717969a5v7f74a753b94f9c8b@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2009/9/21 Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brendan Jurd 2009-09-21 07:07:16 Re: numeric_to_number() function skipping some digits
Previous Message Jaime Casanova 2009-09-21 06:32:40 Re: [PATCH] Largeobject access controls