Re: Re: [GENERAL] +/- Inf for float8's
Thomas Lockhart <lockhart@fourpalms.org>
From: Thomas Lockhart <lockhart@fourpalms.org>
To: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Ross J. Reedstrom" <reedstrm@rice.edu>, Bruce Momjian <pgman@candle.pha.pa.us>, Thomas Lockhart <lockhart@alumni.caltech.edu>, pgsql-hackers@postgreSQL.org
Date: 2001-06-05T03:07:04Z
Lists: pgsql-hackers
> > -infinity < normal values < infinity < NaN < NULL
> I was thinking about making NaN equivalent to NULL. That would give
> consistency in ordering, and probably also in arithmetic. Additionally,
> if the platform supports it we ought to make the Invalid Operation FP
> exception (which yields NaN) configurable: either get NULL or get an
> error.
I'd like to see the distinction between NaN and NULL retained, since the
two "values" arise from different circumstances and under different
conditions. If a particular app needs them to be equivalent, then that
is easy enough to do with SQL or triggers.
- Thomas
On a modestly related note, I'm come over to the notion that the
date/time value 'current' could be ripped out eventually. Tom, isn't
that the only case for those types which bolluxes up caching of
date/time types?