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/
