Re: numeric_to_number() function skipping some digits
| От | Jeevan Chalke |
|---|---|
| Тема | Re: numeric_to_number() function skipping some digits |
| Дата | |
| Msg-id | be46a4f30909202310k1cf7dde2n8ac49319d570fff@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: numeric_to_number() function skipping some digits (Brendan Jurd <direvus@gmail.com>) |
| Ответы |
Re: numeric_to_number() function skipping some digits
|
| Список | pgsql-hackers |
Hi,
--
Jeevan B Chalke
EnterpriseDB Software India Private Limited, Pune
Visit us at: www.enterprisedb.com
---
If better is possible, then good is not enough
On Sat, Sep 19, 2009 at 1:52 AM, Brendan Jurd <direvus@gmail.com> wrote:
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;
Do you mean this is the expected behaviour then?
2009/9/19 Tom Lane <tgl@sss.pgh.pa.us>:> Should we have it throw an error if the input corresponding to a GIt would be a substantial change to the behaviour, and to do it
> symbol doesn't match the expected group separator? I'm concerned that
> that would break applications that work okay today.
>
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
В списке pgsql-hackers по дате отправления: