Re: NaN support in NUMERIC data type

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Sam Mason <sam(at)samason(dot)me(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: NaN support in NUMERIC data type
Date: 2009-04-07 16:51:21
Message-ID: 17132.1239123081@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sam Mason <sam(at)samason(dot)me(dot)uk> writes:
> I've just noticed that the NUMERIC input function special cases NaN
> values differently to the floating point input functions. For example
> the following are all accepted (on my system anyway):

> SELECT 'NaN'::float8;
> SELECT ' NaN'::float8;
> SELECT 'NaN '::float8;
> SELECT '+NaN'::float8;
> SELECT '-NaN'::float8;

> whereas only the first is OK for numeric. Is this deliberate?

Well, the +- part must be an artifact of your strtod() implementation;
our own code isn't doing anything to accept that. I think it's pretty
bogus --- NaNs do not have signs.

IIRC, the explicit support for leading/trailing spaces is something that
we added in float8in long after numeric_in was written, and I think just
nobody thought about numeric at the time. But it's clearly inconsistent
to allow spaces around a regular value but not a NaN.

Possibly the logic for leading/trailing spaces could be pulled out
of set_var_from_str and executed in numeric_in instead?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-04-07 17:46:16 Re: Solution of the file name problem of copy on windows.
Previous Message Hiroshi Saito 2009-04-07 16:40:49 Solution of the file name problem of copy on windows.