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-09 01:31:04
Message-ID: CAKFQuwYc20fBq9OwYCzi0bbCiSdB42Lxxm_aepC4AAg5DpjFKg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, May 8, 2024 at 5:50 PM David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:

>
> Immaterial, they ignore @extschema@ already.
>
>
On a related note, our documentation says:

The target schema is determined by the schema parameter in the control file
if that is given, otherwise by the SCHEMA option of CREATE EXTENSION if
that is given, otherwise the current default object creation schema (the
first one in the caller's search_path).

However:

cat testext--1.1.control
schema=pg_control

cat testext--1.0--1.1.sql
CREATE TABLE public.testtbl2(id text primary key);
INSERT INTO public.testtbl2 VALUES ('@extschema@');

postgres=# create extension testext;
CREATE EXTENSION
postgres=# alter extension testext update to '1.1';
ALTER EXTENSION
postgres=# select * from testtbl2;
id
--------
public

So it actually comes from pg_catalog, not the control file.

David J.

n.b.: just realized I typo'd schema pg_catalog as pg_control, though as
seen that doesn't change the tests at all.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2024-05-09 01:50:58 Re: Upgrading an extension's extnamespace from user-specified to a defined schema breaks dump/restore
Previous Message David G. Johnston 2024-05-09 00:50:20 Re: Upgrading an extension's extnamespace from user-specified to a defined schema breaks dump/restore