(Side note: Folks, we need a real bug/issue-tracking system. We just
discussed this a month ago ("How PostgreSQL's floating point hurts
everyone everywhere"). If anyone's interested in porting Bugzilla or some
other such system to PostgreSQL and putting it into use, let me know.)
Ross J. Reedstrom writes:
> Yeah, need to get Peter Eisentraut involved, perhaps. Should actually be
> pretty simple: the #define is already there: UNSAFE_FLOATS. Define that,
> and the CheckFloat[48]Val functions just return true.
Show me a system where it doesn't work and we'll get it to work.
UNSAFE_FLOATS as it stands it probably not the most appropriate behaviour;
it intends to speed things up, not make things portable.
> > NULL and NaN are not quite the same thing imho. If we are allowing NaN
> > in columns, then it is *known* to be NaN.
>
> For the purposes of ordering, however, they are very similar.
Then we can also treat them similar, i.e. sort them all last or all first.
If you have NaN's in your data you wouldn't be interested in ordering
anyway.
> we check to make sure it's not NaN/+/-Inf (gah, need a shorthand word
> for those three values), else elog().
"non-finite values"
Side note 2: The paper "How Java's floating point hurts everyone
everywhere" provides for good context reading.
Side note 3: Once you read that paper you will agree that using floating
point with Postgres is completely insane as long as the FE/BE protocol is
text-based.
--
Peter Eisentraut Sernanders väg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
