Emre Hasegeli <emre@hasegeli.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
