Re: NaN support in NUMERIC data type

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: NaN support in NUMERIC data type
Дата
Msg-id 17132.1239123081@sss.pgh.pa.us
обсуждение исходный текст
Ответ на NaN support in NUMERIC data type  (Sam Mason <sam@samason.me.uk>)
Ответы Re: NaN support in NUMERIC data type  (Sam Mason <sam@samason.me.uk>)
Список pgsql-hackers
Sam Mason <sam@samason.me.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Hiroshi Saito"
Дата:
Сообщение: Solution of the file name problem of copy on windows.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Solution of the file name problem of copy on windows.