Peter Eisentraut <peter_e(at)gmx(dot)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
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
Possibly this logic could be folded right into the PG_RETURN_FLOAT
> if the platform supports it we ought to make the Invalid Operation FP
> exception (which yields NaN) configurable: either get NULL or get an
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
In response to
pgsql-hackers by date
|Next:||From: Joe Conway||Date: 2001-06-02 22:14:41|
|Subject: Re: Fw: Isn't pg_statistic a security hole - Solution Proposal |
|Previous:||From: Peter Eisentraut||Date: 2001-06-02 20:50:03|
|Subject: Re: Re: [GENERAL] +/- Inf for float8's |