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

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Upgrading an extension's extnamespace from user-specified to a defined schema breaks dump/restore
Дата
Msg-id CAKFQuwayeW5=9rDHrSkSDbR6SW6sEpzpRxcVz64iKKwra4ysyA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Upgrading an extension's extnamespace from user-specified to a defined schema breaks dump/restore  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Upgrading an extension's extnamespace from user-specified to a defined schema breaks dump/restore
Re: Upgrading an extension's extnamespace from user-specified to a defined schema breaks dump/restore
Список pgsql-bugs
On Wed, May 8, 2024 at 3:29 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Mon, Apr 15, 2024 at 8:15 PM David G. Johnston <
> david.g.johnston@gmail.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.


 

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Upgrading an extension's extnamespace from user-specified to a defined schema breaks dump/restore
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Upgrading an extension's extnamespace from user-specified to a defined schema breaks dump/restore