James Coleman <jtc...@gmail.com> writes:
> On Mon, Dec 21, 2020 at 2:59 AM Michael Paquier <mich...@paquier.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
