Re: GiST index build versus NaN coordinates

I wrote:
> Andreas Seltenreich <seltenreich(at)gmx(dot)de> writes:
>> The infinite loop from the bug report was triggered. Further, two
>> previously unseen errors are logged:
>> ERROR: timestamp cannot be NaN
>> ERROR: getQuadrant: impossible case
>> The first is porbably as boring as it gets, the second one is from the
>> getQuadrant() in spgquadtreeproc.c.

> Yeah, the first one is presumably from float8_timestamptz() intentionally
> rejecting a NaN, which seems fine.

>> Curiously, the getQuadrant()s in geo_spgist.c and rangetypes_spgist.c do
>> not have such a check. I guess the boxes will just end up in an
>> undefined position in the index for these.

> Right, we probably want them all to apply some consistent ordering ---
> doesn't matter so much what it is, but float8's rule is as good as any.

I looked into these a bit more closely. I think rangetypes_spgist.c is
fine as-is: it's relying on the range component type to provide a total
ordering of its values, and if the component type fails to do that, it's
the fault of the component type not the range code.

spgquadtreeproc.c and geo_spgist.c both have got NaN issues, but the code
in both of them is rather tightly tied to the fuzzy-geometric-comparisons
logic that Emre has been messing with. I think we ought to put "what
to do with NaNs?" into that same can of worms, rather than try to resolve
it separately. (Yeah, I know, I just made Emre's job even harder.)

regards, tom lane