> flost8_lt and its family functions are provided to unify the
> sorting order including NaN. NaN is not rejected by the usage of
> float8_lt in the case but it is what the function is expected to
> be used for. If we wanted to check if it is positive, it
> unexpectedly throws an exception. (I suppose that NaNs should be
> silently ignored rather than stopping a query by throwng an
> exception.)
It would at least be dump-and-restore hazard if we don't let them in.
The new version allows NaNs.
> This gives a wrong result for NaN-containing objects.
I removed the NaN aware comparisons from FP macros, and carefully
reviewed the places that needs to be NaN aware.
I am sorry that it took so long for me to post the new versions. The
more I get into this the more problems I find. The new versions
include non-trivial changes. I would be glad if you can look into
them.