> I am not sure how useful NaNs are in geometric types context, but we
> allow them, so inconsistent hypot() would be a problem. I will change
> my patches to keep pg_hypot().
New versions of the patches are attached with 2 additional ones. The
new versions leave pg_hypot() in place. One of the new patches
improves the test coverage. The line coverage of geo_ops.c increases
from 55% to 81%. The other one fixes -0 values to 0 on float
operators. I am not sure about performance implication of this, so
kept it separate. It may be a better idea to check this only on the
platforms that has tendency to produce -0.
While working on the tests, I found some unreachable code and removed
it. I also found that lseg ## lseg operator returning wrong results.
It is defined as "closest point to first segment on the second
segment", but:
> # select '[(1,2),(3,4)]'::lseg ## '[(0,0),(6,6)]'::lseg;
> ?column?
> ----------
> (1,2)
> (1 row)
I appended the fix to the patches. This is also effecting lseg ## box operator.
I also changed recently band-aided point ## lseg operator to return
the point instead of NULL when it cannot find the correct result to
avoid the operators depending on this one to crash.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
