On Tue, Dec 22, 2020 at 1:03 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> James Coleman <jtc331@gmail.com> writes:
> > On Mon, Dec 21, 2020 at 2:59 AM Michael Paquier <michael@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.
Thank you for the comments!
I understand that it is intentional behavior and the downside of my
idea. But what is the difference between the schema created by
specifying the schema option in the control file and by CREATE SCHEMA
in the install script? Extensions might create the same schema
"schema1" in their install script. In this case, dropping the first
one force dropping the rest. Looking at some extensions in the world.
some extensions use the schema option whereas some use the install
script. I think it’s reasonable there are two ways to create the
extension’s schema with different dependencies but I think it’s better
to be documented. It looked like a non-intuitive behavior when I saw
it for the first time.
Regards,
--
Masahiko Sawada
EnterpriseDB: https://www.enterprisedb.com/
