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/
