NaN support in NUMERIC data type

From: Sam Mason <sam(at)samason(dot)me(dot)uk>
To: pgsql-hackers(at)postgresql(dot)org
Subject: NaN support in NUMERIC data type
Date: 2009-04-07 15:53:59
Message-ID: 20090407155359.GG12225@frubble.xen.chris-lamb.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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/

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2009-04-07 16:05:59 Re: [HACKERS] string_to_array with empty input
Previous Message justin 2009-04-07 15:13:15 Re: [HACKERS] string_to_array with empty input