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:
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.
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.
regards
Andreas
Footnotes:
[1]
create function smith_double_inf() returns float as $$select
'infinity'::float$$ language sql immutable;
create function smith_double_ninf() returns float as $$select
'-infinity'::float$$ language sql immutable;
create function smith_double_nan() returns float as $$select 'nan'::float$$
language sql immutable;
create function smith_real_nan() returns real as $$select 'nan'::real$$
language sql immutable;
create function smith_real_inf() returns real as $$select 'infinity'::real$$
language sql immutable;
create function smith_real_ninf() returns real as $$select '-infinity'::real$$
language sql immutable;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
