Hi, 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? A quick check of utils/adt/numeric.c would suggest that it's been special cased as a optimisation so we don't allocate a numeric value in set_var_from_str() unless we need to. As a side note; I'm only really interested in the leading/trailing spaces. I only noticed the leading plus/minus sign when reading the code and think it's probably better if a NaN is rejected if it has a leading sign. I think it would be better if it was consistent with FLOAT, not sure how to do this in a platform independent way though. I could submit a patch if you want; I'm unsure whether it's better to duplicate code in numeric_in, do slightly more work and allocate memory for NaN's when not strictly needed, or remove knowledge of NumericVar from numeric_in altogether and push code into set_var_from_str. Comments? -- Sam http://samason.me.uk/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
