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?
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/5405b243-4523-266e-6139-ad9f80a9d9fc%40postgrespro.ru