pgsql: Prevent ALTER TYPE/DOMAIN/OPERATOR from changing extension membe

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Prevent ALTER TYPE/DOMAIN/OPERATOR from changing extension membe
Date: 2021-08-17 18:29:36
Message-ID: E1mG3qC-0001mr-RL@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Prevent ALTER TYPE/DOMAIN/OPERATOR from changing extension membership.

If recordDependencyOnCurrentExtension is invoked on a pre-existing,
free-standing object during an extension update script, that object
will become owned by the extension. In our current code this is
possible in three cases:

* Replacing a "shell" type or operator.
* CREATE OR REPLACE overwriting an existing object.
* ALTER TYPE SET, ALTER DOMAIN SET, and ALTER OPERATOR SET.

The first of these cases is intentional behavior, as noted by the
existing comments for GenerateTypeDependencies. It seems like
appropriate behavior for CREATE OR REPLACE too; at least, the obvious
alternatives are not better. However, the fact that it happens during
ALTER is an artifact of trying to share code (GenerateTypeDependencies
and makeOperatorDependencies) between the CREATE and ALTER cases.
Since an extension script would be unlikely to ALTER an object that
didn't already belong to the extension, this behavior is not very
troubling for the direct target object ... but ALTER TYPE SET will
recurse to dependent domains, and it is very uncool for those to
become owned by the extension if they were not already.

Let's fix this by redefining the ALTER cases to never change extension
membership, full stop. We could minimize the behavioral change by
only changing the behavior when ALTER TYPE SET is recursing to a
domain, but that would complicate the code and it does not seem like
a better definition.

Per bug #17144 from Alex Kozhemyakin. Back-patch to v13 where ALTER
TYPE SET was added. (The other cases are older, but since they only
affect the directly-named object, there's not enough of a problem to
justify changing the behavior further back.)

Discussion: https://postgr.es/m/17144-e67d7a8f049de9af@postgresql.org

Branch
------
REL_14_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/8f51ee63df3a9022cfd07d7482b8f3f21ff8f46d

Modified Files
--------------
src/backend/catalog/pg_depend.c | 7 +++++++
src/backend/catalog/pg_operator.c | 15 +++++++++++----
src/backend/catalog/pg_type.c | 24 ++++++++++++++++--------
src/backend/commands/operatorcmds.c | 2 +-
src/backend/commands/typecmds.c | 2 ++
src/include/catalog/pg_operator.h | 4 +++-
src/include/catalog/pg_type.h | 1 +
7 files changed, 41 insertions(+), 14 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message houzj.fnst@fujitsu.com 2021-08-18 01:16:50 RE: pgsql: pgstat: Bring up pgstat in BaseInit() to fix uninitialized use o
Previous Message Tom Lane 2021-08-17 17:00:41 pgsql: Reduce assumptions about locale's behavior in new regex tests.