Re: Re: [BUGS] Unnexpected results using to_number()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
Cc: Andrew Snow <andrew(at)modulus(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [BUGS] Unnexpected results using to_number()
Date: 2000-07-10 14:12:46
Message-ID: 124.963238366@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> writes:
>> 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.

Well, I think there is a good reason for the difference in Oracle's
behavior. The second case is presumably returning a zero-length string,
not a NULL, and that is a perfectly valid string. to_number() has no
comparable option, so I think it makes sense for it to raise an error.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Matthew Altus 2000-07-11 02:02:46 Re: ps_status.h on FreeBSD 4.0 problems and fix
Previous Message Karel Zak 2000-07-10 07:32:37 Re: Re: [BUGS] Unnexpected results using to_number()

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2000-07-10 14:14:32 Re: AW: Re: postgres TODO
Previous Message Tom Lane 2000-07-10 14:08:58 Re: Progress report: intraquery memory recovery in executor