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