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