Andreas Seltenreich <seltenre...@gmx.de> writes:
> Tom Lane writes:
>> 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.
> Sounds like some fuzz testing with nan/infinity is in order. sqlsmith
> doesn't generate any float literals, but it calls functions to satisfy
> its need for values of specific types. Adding suitable functions[1] to
> the regression db, I made the following observations:
This is really useful, thanks!
> 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.
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
