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
|
Список | 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 по дате отправления: