Re: [PATCH] remove deprecated v8.2 containment operators

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Stephen Frost <sfrost(at)snowman(dot)net>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] remove deprecated v8.2 containment operators
Date: 2020-11-12 22:28:20
Message-ID: 235561.1605220100@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Krasiyan Andreev 2020-11-12 22:35:20 Re: Implement <null treatment> for window functions
Previous Message Tom Lane 2020-11-12 22:16:33 Re: Bogus documentation for bogus geometric operators