pg.ddx.io  pgsql-committers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-committers@lists.postgresql.org
Subject: pgsql: Explicitly list dependent types as extension members in pg_depen
Date: Mon, 04 Mar 2024 19:49:48 +0000
Message-ID: <E1rhEJn-0024wH-TS@gemulon.postgresql.org> (raw)

Explicitly list dependent types as extension members in pg_depend.

Auto-generated array types, multirange types, and relation rowtypes
are treated as dependent objects: they can't be dropped separately
from the base object, nor can they have their own ownership or
permissions.  We previously felt that, for objects that are in an
extension, only the base object needs to be listed as an extension
member in pg_depend.  While that's sufficient to prevent inappropriate
drops, it results in undesirable answers if someone asks whether a
dependent type belongs to the extension.  It looks like the dependent
type is just some random separately-created object that happens to
depend on the base object.  Notably, this results in postgres_fdw
concluding that expressions involving an array type are not shippable
to the remote server, even when the defining extension has been
whitelisted.

To fix, cause GenerateTypeDependencies to make extension dependencies
for dependent types as well as their base objects, and adjust
ExecAlterExtensionContentsStmt so that object addition and removal
operations recurse to dependent types.  The latter change means that
pg_upgrade of a type-defining extension will end with the dependent
type(s) now also listed as extension members, even if they were
not that way in the source database.  Normally we want pg_upgrade
to precisely reproduce the source extension's state, but it seems
desirable to make an exception here.

This is arguably a bug fix, but we can't back-patch it since it
causes changes in the expected contents of pg_depend.  (Because
it does, I've bumped catversion, even though there's no change
in the immediate post-initdb catalog contents.)

Tom Lane and David Geier

Discussion: https://postgr.es/m/4a847c55-489f-4e8d-a664-fc6b1cbe306f@gmail.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/e5bc9454e527b1cba97553531d8d4992892fdeef

Modified Files
--------------
src/backend/catalog/pg_type.c                      |  17 ++-
src/backend/commands/extension.c                   |  83 +++++++++--
src/include/catalog/catversion.h                   |   2 +-
src/test/modules/test_extensions/Makefile          |   3 +-
.../test_extensions/expected/test_extensions.out   | 159 +++++++++++++++++++--
src/test/modules/test_extensions/meson.build       |   2 +
.../test_extensions/sql/test_extensions.sql        |  13 ++
.../modules/test_extensions/test_ext9--1.0.sql     |   8 ++
src/test/modules/test_extensions/test_ext9.control |   3 +
9 files changed, 265 insertions(+), 25 deletions(-)



Message-ID: <E1rhEJn-0024wH-TS@gemulon.postgresql.org>
Permalink:  ../E1rhEJn-0024wH-TS@gemulon.postgresql.org/
Also on:    postgresql.org/message-id/E1rhEJn-0024wH-TS@gemulon.postgresql.org

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-committers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, pgsql-committers@lists.postgresql.org
  Subject: Re: pgsql: Explicitly list dependent types as extension members in pg_depen
  In-Reply-To: <E1rhEJn-0024wH-TS@gemulon.postgresql.org>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox