Re: BUG #18214: poly_contain (@>) hangs forever for input data with zeros and infinities

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> In postgreses 14-16, you execute following query it will work "forever"

> select '((-inf, 0), (0, inf), (-inf, 0), (0, inf), (0, 0), (0, 0), (0, 0),
> (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0,
> 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0),
> (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0,
> 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0))'::polygon @> '((0, 0), (0, 0),
> (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0,
> 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0),
> (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0,
> 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0), (0, 0),
> (-inf, 0))'::polygon;

I poked at this a bit. v13 and earlier return quickly, although their
answer is "false" which I'm not too sure is correct. git bisect shows
the behavior changed at

commit 8597a48d01b6cc0b09ff626253ac93c67e5516d5
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Sat Nov 21 16:46:43 2020 -0500

Fix FPeq() and friends to get the right answers for infinities.

I'm inclined to think that poly_contain_poly, or more specifically
lseg_inside_poly, is just a broken algorithm. I don't have much faith
that it gets the right answer (especially for non-simple polygons,
which we do try to handle correctly in e.g. point_inside), and it's
pretty obviously horrid from a time-complexity standpoint. I think
we need to throw it away and start fresh rather than try to band-aid
it further.

I googled "polygon containment" and read about sweep-line algorithms,
which might be the way to go here, but it's not something I care to
put time into personally.

> My colleagues have poked this bug a bit, and suggested that the cause of the
> problem is probably the lseg_contain_point(LSEG *lseg, Point *pt) function,
> that gives wrong result for the infinity case.

Hmm, yeah, that pretty obviously fails for infinities, or any values
large enough to cause overflow. I doubt that fixing it is sufficient
to rescue poly_contain_poly, but it seems worth improving anyway
because it has other callers. Not quite sure how we should define
its behavior for infinity inputs though. If the point has any Inf
coordinate, it seems clear that it's on the segment only if it is
equal() to one of the endpoints. But what about a finite point
versus a segment with Inf coordinate(s)?

regards, tom lane