Re: Upgrading an extension's extnamespace from user-specified to a defined schema breaks dump/restore

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Bug List <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Upgrading an extension's extnamespace from user-specified to a defined schema breaks dump/restore
Date: 2024-05-08 23:12:47
Message-ID: CAKFQuwayeW5=9rDHrSkSDbR6SW6sEpzpRxcVz64iKKwra4ysyA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, May 8, 2024 at 3:29 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > On Mon, Apr 15, 2024 at 8:15 PM David G. Johnston <
> > david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> >> tl/dr - alter extension ... set schema ... needs to update
> >> pg_extension.extnamespace if the named schema matches the current value
> in
> >> the control file. Otherwise, extension authors can and have introduced
> a
> >> dump/restore failure mode that the DBA can only fix via direct catalog
> >> manipulation.
>
> > Tom's recent bug regarding alter extension reminded me that no has
> > expressed an opinion on this one.
>
> A quick test says that ALTER EXTENSION SET SCHEMA *does* update
> pg_extension.extnamespace to the new schema.
>
> Re-reading your original message, I'm of the opinion that pg_cron's
> control files are probably broken. If they are changing from
> relocatable to not, then they need to specify that property in
> a version-specific control file not the main one. Maybe there's
> something else that needs to happen in our code, but updating
> extnamespace doesn't seem to be it. Also, I do see code that
> purports to cope with a version-related update of the relocatable
> flag --- whether we test that, I'm not sure, but there's not
> something obviously missing.
>
>
Let me simplify this a bit. But the parameter "relocatable" has nothing to
do with this, "schema" does.

===========================
> cat testext.control
comment = 'testing extension'
default_version = '1.0'
relocatable = false
trusted = false

> cat testext--1.1.control
schema=pg_control

postgres=# create extension testext;
CREATE EXTENSION
postgres=# \dx
List of installed extensions
Name | Version | Schema | Description
---------+---------+------------+------------------------------
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
testext | 1.0 | public | testing extension
(2 rows)

postgres=# alter extension testext update to '1.1';
ALTER EXTENSION
postgres=# \dx
List of installed extensions
Name | Version | Schema | Description
---------+---------+------------+------------------------------
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
testext | 1.1 | public | testing extension
(2 rows)

postgres=# alter extension testext set schema pg_catalog;
ERROR: extension "testext" does not support SET SCHEMA
================================

The update succeeds but the value for schema does not change ignoring the
explicit schema now present in testext--1.1.control

The subsequent error during alter extension shows that the system is aware
of the newly added schema setting.

We are being inconsistent here - especially since create extension does
allow a schema to be named so long as it matches the one in the control
file.

David J.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2024-05-08 23:32:43 Re: Upgrading an extension's extnamespace from user-specified to a defined schema breaks dump/restore
Previous Message Tom Lane 2024-05-08 22:29:59 Re: Upgrading an extension's extnamespace from user-specified to a defined schema breaks dump/restore