Peter Eisentraut <peter.eisentr...@enterprisedb.com> writes: > On 2020-10-27 04:25, Justin Pryzby wrote: >> They have been deprecated for a Long Time, so finally remove them for v14. >> Four fewer exclamation marks makes the documentation less exciting, which is >> a >> good thing.
> I have committed the parts that remove the built-in geometry operators > and the related regression test changes. I'm on board with pulling these now --- 8.2 to v14 is plenty of deprecation notice. However, the patch seems incomplete in that the code support for these is still there -- look for RTOldContainedByStrategyNumber and RTOldContainsStrategyNumber. Admittedly, there's not much to be removed except some case labels, but it still seems like we oughta do that to avoid future confusion. > The changes to the contrib modules appear to be incomplete in some ways. > In cube, hstore, and seg, there are no changes to the extension > scripts to remove the operators. All you're doing is changing the C > code to no longer recognize the strategy, but that doesn't explain what > will happen if the operator is still used. In intarray, by contrast, > you're editing an existing extension script, but that should be done by > an upgrade script instead. In the contrib modules, I'm afraid what you gotta do is remove the SQL operator definitions but leave the opclass code support in place. That's because there's no guarantee that users will update the extension's SQL version immediately, so a v14 build of the .so might still be used with the old SQL definitions. It's not clear how much window we need give for people to do that update, but I don't think "zero" is an acceptable answer. (The core code doesn't have to concern itself with such scenarios, since we require the initial catalog contents to match the backend major version. Hence it is okay to remove the code support now in the in-core opclasses.) regards, tom lane