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
