> 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: # select '(3,4),(nan,5)'::box = '(3,4),(nan,5)'::box; ?column? ---------- f (1 row) # select '(3,4),(nan,5)'::box < '(3,4),(nan,5)'::box; ?column? ---------- f (1 row) # select '(3,4),(nan,5)'::box > '(3,4),(nan,5)'::box; ?column? ---------- f (1 row) > More generally, this example makes me fearful that NaN coordinates in > geometric values are likely to cause all sorts of issues. It's too late > to disallow them, probably, but I wonder how can we identify other bugs > of this ilk. Is it reasonable to disallow NaN coordinates on the next major release. Are there any reason to deal with them? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
