Re: Triage for unimplemented geometric operators

On 07/12/2021 06:18, Tom Lane wrote:
> 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.

I agree, seems to be a reasonable compromise. Removing 20+-years old
unused and slightly misleading code probably should overweight the
natural inclination to implement all of the functions promised in the
catalog. Enhancing software by deleting the code is not an everyday
chance and IMHO should be taken, even when it requires an extra
catversion bump.

I am kind of split on whether it is worth it to implement poly_distance
in back branches. Maybe there is a benefit in implementing: it should
not cause any reasonable incompatibilities and will introduce somewhat
better compatibility with v15+. We could even get away with not updating
v10..12' docs on poly_distance because it's not mentioned anyway.

I agree on de-documenting all of the unimplemented functions in v13 and
v14. Branches before v13 should not require any changes (including
documentation) because detailed table on which operators support which
geometry primitives only came in 13, and I could not find in e.g. 12's
documentation any references to the cases you listed previously:
> dist_lb: <->(line,box)
> dist_bl: <->(box,line)
> close_sl: lseg ## line
> close_lb: line ## box
> poly_distance: polygon <-> polygon
> path_center: @@ path

--
Anton Voloshin
Postgres Professional, The Russian Postgres Company
https://postgrespro.ru