On 16.11.2020 23:55, Justin Pryzby wrote:
On Fri, Nov 13, 2020 at 10:03:43AM -0500, Stephen Frost wrote:
* Magnus Hagander (mag...@hagander.net) wrote:
On Thu, Nov 12, 2020 at 11:28 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
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.
Based on my experience from the field, the answer is "never".
As in, most people have no idea they are even *supposed* to do such an
upgrade, so they don't do it. Until we solve that problem, I think
we're basically stuck with keeping them "forever". (and even if/when
we do, "zero" is probably not going to cut it, no)
Yeah, this is a serious problem and one that we should figure out a way
to fix or at least improve on- maybe by having pg_upgrade say something
about extensions that could/should be upgraded..?
I think what's needed are:
1) a way to *warn* users about deprecation. CREATE EXTENSION might give an
elog(WARNING), but it's probably not enough. It only happens once, and if it's
in pg_restore/pg_upgrade, it be wrapped by vendor upgrade scripts. It needs to
be more like first function call in every session. Or more likely, put it in
documentation for 10 years.
2) a way to *enforce* it, like making CREATE EXTENSION fail when run against an
excessively old server, including by pg_restore/pg_upgrade (which ought to also
handle it in --check).
Are there any contrib for which (1) is done and we're anywhere near doing (2) ?
Status update for a commitfest entry.
The commitfest is nearing the end and this thread is "Waiting on
Author". As far as I see we don't have a patch here and discussion is a
bit stuck.
So, I am planning to return it with feedback. Any objections?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
