Re: NaN support in NUMERIC data type

On Tue, Apr 07, 2009 at 12:51:21PM -0400, Tom Lane wrote:
> Sam Mason <sam@samason.me.uk> writes:
> >   SELECT 'NaN'::float8;
> >   SELECT ' NaN'::float8;
> >   SELECT 'NaN '::float8;
> >   SELECT '+NaN'::float8;
> >   SELECT '-NaN'::float8;
>
> 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.

OK, didn't actually check the code with that; no point worrying about it
then.

> 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.

Good, I wanted to make sure it wasn't a deliberate thing before doing
too much.

> Possibly the logic for leading/trailing spaces could be pulled out
> of set_var_from_str and executed in numeric_in instead?

Yes, I didn't want to do this before because it's called from a
couple of other places.  I looked again and realised that we're
generating those in very fixed formats so don't need to worry about
leading/trailing spaces and hence can move the code up to numeric_in.

The attached patch gives set_var_from_str an "endptr" similar to strtod
so handling is closer to the float[48]in code.  I moved error reporting
code outside as well to cut down on the multiple identical calls.

The included patch was generated against 8.3.5 (because that's what I
had lying around when I started playing) but applies with a little fuzz
to the latest snapshot and does the right thing for me in both versions.

--
  Sam  http://samason.me.uk/