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
