Peter Eisentraut <peter.eisentraut@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