Re: Re: [BUGS] Unnexpected results using to_number()
От | Karel Zak |
---|---|
Тема | Re: Re: [BUGS] Unnexpected results using to_number() |
Дата | |
Msg-id | Pine.LNX.3.96.1000710091930.24431C-100000@ara.zf.jcu.cz обсуждение исходный текст |
Ответ на | Re: Re: [BUGS] Unnexpected results using to_number() (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: [BUGS] Unnexpected results using to_number()
|
Список | pgsql-hackers |
On Mon, 10 Jul 2000, Tom Lane wrote: > Karel Zak <zakkr@zf.jcu.cz> writes: > > On Sun, 9 Jul 2000, Tom Lane wrote: > >> "Andrew Snow" <andrew@modulus.org> writes: > >>>> # SELECT to_number('12,454.8-', ''); > >>>> pqReadData() -- backend closed the channel unexpectedly. > >> > >> In current sources I get a NULL result, which seems to be what the > >> code author intended originally. However this seems a little bit > > > my original code not return NULL, but return numeric_in(NULL, 0, 0) for > > this situation. > > Yeah, I know. What did you expect that to produce, if not a NULL? It is a numeric_in() problem :-), but yes, it is still NULL. > > >> inconsistent --- shouldn't it raise a bad-format error instead? > > What do you think about raising an error instead of returning NULL? Oracle: SVRMGR> select to_number('12,454.8-', '') from dual; TO_NUMBER( ---------- ORA-01722: invalid number I mean that we can use ERROR here too. My original idea was same form for to_char and for to_number --- for to_char() Oracle say: SVRMGR> select to_char(SYSDATE, '') from dual; TO_CHAR(S --------- 1 row selected. I not sure here what is better. If you mean that ERROR is better I will change it in some next patch fot formattin.c. Comments? Karel
В списке pgsql-hackers по дате отправления: