Re: Dependency isn't created between extension and schema

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: James Coleman <jtc331(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Dependency isn't created between extension and schema
Date: 2020-12-21 16:03:13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

James Coleman <jtc331(at)gmail(dot)com> writes:
> On Mon, Dec 21, 2020 at 2:59 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>> On Mon, Dec 21, 2020 at 04:02:29PM +0900, Masahiko Sawada wrote:
>>> Is it a bug? Since the created schema obviously depends on the
>>> extension when we created the schema specified in the schema option, I
>>> think we might want to create the dependency so that DROP EXTENSION
>>> drops the schema as well.

>> FWIW, I recall that the "soft" behavior that exists now is wanted, as
>> it is more flexible for DROP EXTENSION: what you are suggesting here
>> has the disadvantage to make DROP EXTENSION fail if any non-extension
>> object has been created on this schema, so this could be disruptive
>> when it comes to some upgrade scenarios.

I think it absolutely is intentional. For example, if several extensions
all list "schema1" in their control files, and you install them all, you
would not want dropping the first-created one to force dropping the rest.
I do not really see any problem here that's worth creating such hazards
to fix.

(At least in current usage, I think that control files probably always
list common schemas not per-extension schemas, so that this scenario
would be the norm not the exception.)

> Alternatively the behavior could be updated to match the docs, since
> that seems like reasonable intent.

That documentation is talking about the SCHEMA option in CREATE EXTENSION,
which is an entirely different matter from the control-file option.
A control-file entry is not going to know anything about the specific
installation it's being installed in, while the user issuing CREATE
EXTENSION presumably has local knowledge; so I don't see any strong
argument that the two cases must be treated alike.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-12-21 16:23:07 Re: bad dependency in pg_dump output related to support function breaks binary upgrade
Previous Message Konstantin Knizhnik 2020-12-21 15:22:23 Inconsistent/confusing handling of tablespaces for partitioned tables