Re: GiST index build versus NaN coordinates

Emre Hasegeli <emre(at)hasegeli(dot)com> writes:
>> I think that probably the most reasonable answer is to replace all the
>> raw "double" comparisons in this code with float8_cmp_internal() or
>> something that's the moral equivalent of that. Does anyone want to
>> propose something else?

> We can probably get away by changing the comparison on the GiST code.
> It is not likely to cause inconsistent results. Comparisons with NaN
> coordinates don't return true to anything, anyway:

Yes, and that is itself inconsistent with the behavior of the primitive
float8 datatype:

regression=# select '4'::float8 < 'NaN'::float8;
?column?
----------
t
(1 row)

I'm inclined to think that we ought to try to make NaNs in geometric types
work like float8 thinks they work, ie they compare higher than non-NaNs.
Yeah, it would make an IEEE-spec purist blanch, but there is no room for
unordered values in a datatype that you would like to be indexable, or
groupable.

> Is it reasonable to disallow NaN coordinates on the next major
> release. Are there any reason to deal with them?

I don't see how we can do that; what would you do about tables already
containing NaNs? Even without that consideration, assuming that there's
no way a NaN could creep in seems a pretty fragile assumption, considering
that operations like Infinity/Infinity will produce one.

regards, tom lane