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: "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, 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 20:31:27
Message-ID: 23801.991513887@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
[ continuing a discussion from last August ]

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Bruce Momjian writes:
>> My assumption is that we never came up with any solution to this, right?

> It stopped when we noticed that proper support for non-finite values will
> break indexing, because the relational trichotomy doesn't hold.

I believe that's not a problem anymore.  The current form of the float
comparison functions will perform sorting and comparisons according to
the sequence

	-infinity < normal values < infinity < NaN < NULL

with all NaNs treated as equal.  This may not be exactly what an IEEE
purist would like, but given that we have to define *some* consistent
sort order, it seems as reasonable as we can get.

Accordingly, I suggest that Ross go back to work on persuading the code
to treat infinities and NaNs properly in other respects.  IIRC, there
are still open issues concerning whether we still need/want
CheckFloat8Val/CheckFloat4Val, what the I/O conversion functions should
do on non-IEEE machines, etc.  They all seemed soluble, though.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2001-06-02 20:50:03
Subject: Re: Re: [GENERAL] +/- Inf for float8's
Previous:From: Vince VielhaberDate: 2001-06-02 16:56:57
Subject: Re: Re: Interesting Atricle

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