I wrote:
> Andreas Seltenreich <seltenre...@gmx.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
