Re: Triage for unimplemented geometric operators - Mailing list pgsql-hackers

From Laurenz Albe
Subject Re: Triage for unimplemented geometric operators
Date
Msg-id 4d457eb18021a7ec5dde68098f007ef3d552c1f4.camel@cybertec.at
Whole thread Raw
In response to Triage for unimplemented geometric operators  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 2021-12-06 at 18:18 -0500, Tom Lane wrote:
> Over in [1] it was pointed out that I overenthusiastically
> documented several geometric operators that, in fact, are
> only stubs that throw errors when called.  Specifically
> these are
> 
> dist_lb:        <->(line,box)
> dist_bl:        <->(box,line)
> close_sl:       lseg ## line
> close_lb:       line ## box
> poly_distance:  polygon <-> polygon
> path_center:    @@ path
> (this also underlies point(path), which is not documented anyway)
> 
> There are three reasonable responses:
> 
> 1. Remove the documentation, leave the stubs in place;
> 2. Rip out the stubs and catalog entries too (only possible in HEAD);
> 3. Supply implementations.
> 
> I took a brief look at these, and none of them seem exactly hard
> to implement, with the exception of path_center which seems not to
> have a non-arbitrary definition.  (We could model it on poly_center
> but that one seems rather arbitrary; also, should open paths behave
> any differently than closed ones?)  close_lb would also be rather
> arbitrary for the case of a line that intersects the box, though
> we could follow close_sb's lead and return the line's closest point
> to the box center.
> 
> On the other hand, they've been unimplemented for more than twenty years
> and no one has stepped forward to fill the gap, which sure suggests that
> nobody cares and we shouldn't expend effort and code space on them.
> 
> The only one I feel a bit bad about dropping is poly_distance, mainly
> on symmetry grounds: we have distance operators for all the geometric
> types, so dropping this one would leave a rather obvious hole.  The
> appropriate implementation seems like a trivial copy and paste job:
> distance is zero if the polygons overlap per poly_overlap, otherwise
> it's the same as the closed-path case of path_distance.
> 
> So my inclination for HEAD is to implement poly_distance and nuke
> the others.  I'm a bit less sure about the back branches, but maybe
> just de-document all of them there.
> 
> Thoughts?
>
> [1] https://www.postgresql.org/message-id/flat/5405b243-4523-266e-6139-ad9f80a9d9fc%40postgrespro.ru

I agree with option #2 for HEAD; if you feel motivated to implement
"poly_distance", fine.

About the back branches, removing the documentation is a good choice.

I think the lack of complaints is because everybody who needs serious
geometry processing uses PostGIS.

Yours,
Laurenz Albe




pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: parallel vacuum comments
Next
From: Amit Kapila
Date:
Subject: Re: pg_get_publication_tables() output duplicate relid