> > Seems at some point someone decided not to be machine-independent in
> > backend/utils/adt/float.c
That was me.
> > Redhat 5.2 system with gcc 2.8.1 doesn't define NAN unless
> > _GNU_SOURCE is defined first. Although include/utils/dt.h *does*
> > check for NAN (and HUGE_VAL) before using them, the float.c doesn't.
> > What happened?
> the new NUMERIC data type started recently a discussion about
> NAN, because I tried to be able to convert NAN from/to
> float's, and that started some trouble. I'm not sure how this
> went into adt/float.c. At least I think we should fix all the
> NAN handling for v6.5.
Jan started with NAN handling for numeric, and I'd already done the same
thing for the date/time types quite a while ago. We also had a
discussion recently that we should be handling 'NaN' and 'Infinity' on
float8 input values so that dump/reload is more robust and symmetric, so
I added that in ('-Infinity' still needs to be done).
I added in the new code, knowing that there was some fixup and
consolidation which needs to be done. Unless someone has worked out
another scheme, I'd suggest using the date/time code in dt.h as an
example to work from. We might want to use PG_NAN and PG_INFINITY, which
we can then define in one central place.
If someone want to work this out, I'd be happy to use the result. Or I
can do something directly. I'd like a solution with the equivalent of
NAN and HUGE_VAL (and -HUGE_VAL). Jan? Taral?
- Tom
