Skip site navigation (1) Skip section navigation (2)

Re: Re: [GENERAL] +/- Inf for float8's

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Re: [GENERAL] +/- Inf for float8's
Date: 2001-06-02 21:11:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
returning NaNs:
	if (isnan(x))
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
> 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

In response to

pgsql-hackers by date

Next:From: Joe ConwayDate: 2001-06-02 22:14:41
Subject: Re: Fw: Isn't pg_statistic a security hole - Solution Proposal
Previous:From: Peter EisentrautDate: 2001-06-02 20:50:03
Subject: Re: Re: [GENERAL] +/- Inf for float8's

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group