Peter Eisentraut <peter_e@gmx.net> writes:
> I was thinking about making NaN equivalent to NULL.
Mumble ... in the thread last August, someone made the point that SQL's
idea of NULL ("unknown value") is not really the same as a NaN ("I know
that this is not a well-defined number"). Even though there's a lot of
similarity in the behaviors, I'd be inclined to preserve that semantic
distinction.
If we did want to do this, the implication would be that all
float-returning functions would be required to make sure they were not
returning NaNs:if (isnan(x)) PG_RETURN_NULL();else PG_RETURN_FLOAT8(x);
Possibly this logic could be folded right into the PG_RETURN_FLOAT
macros.
> 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.
Seems like we could equally well offer the switch as "either get NaN
or get an error".
Something to be kept in mind here is the likelihood of divergence in
our behavior between IEEE and non-IEEE platforms. I don't object to
that --- it's sort of the point --- but we should be aware of how much
difference we're creating, and try to avoid unnecessary differences.
Hmm ... I suppose an attraction of a NULL-vs-error, as opposed to NaN-
vs-error, option is that it could theoretically be supported on NaN-less
hardware. But is that realizable in practice? SIGFPE is messy.
regards, tom lane
