Emre Hasegeli <e...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers