Re: [PATCH] remove deprecated v8.2 containment operators
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
Heikki Linnakangas <hlinnaka@iki.fi>,
Stephen Frost <sfrost@snowman.net>,
Ian Lawrence Barwick <barwick@gmail.com>, pgsql-hackers@postgresql.org
Date: 2020-11-12T22:28:20Z
Lists: pgsql-hackers
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
Commits
-
Doc: remove obsolete entries in table of BRIN strategy numbers.
- 0ce4cd04da55 14.0 landed
-
Remove deprecated containment operators for contrib types.
- 112d411fbeb5 14.0 landed
-
Remove unused and deprecated strategy numbers from BRIN code
- d93ccdea1d44 14.0 landed
-
Remove code handling removed deprecated containment operators
- 591d282e8d3e 14.0 landed
-
Remove deprecated containment operators for built-in types
- 2f70fdb0644c 14.0 landed
-
Remove use of deprecated containment operators in tests
- 3165426e54df 14.0 landed