Re: ALTER TYPE vs extension membership (was Re: BUG #17144: Upgrade from v13 to v14 with the cube extension failed) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: ALTER TYPE vs extension membership (was Re: BUG #17144: Upgrade from v13 to v14 with the cube extension failed)
Date
Msg-id 20210817112233.tiheqcydqf4bariw@alap3.anarazel.de
Whole thread Raw
In response to ALTER TYPE vs extension membership (was Re: BUG #17144: Upgrade from v13 to v14 with the cube extension failed)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ALTER TYPE vs extension membership (was Re: BUG #17144: Upgrade from v13 to v14 with the cube extension failed)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2021-08-16 15:36:59 -0400, Tom Lane wrote:
> There's a policy question here, which is when does an operation on
> a pre-existing object within an extension script cause the object
> to be absorbed into the extension?  You might naively say "never",
> but that's not our historical behavior, and I think it'd clearly
> be the wrong thing in some cases.  For example, consider
> 
> CREATE TYPE cube;   -- make a shell type
> -- do something that requires type cube to exist
> CREATE EXTENSION cube;
> 
> We don't want this to fail, because it might be necessary to do
> things that way to get out of circular dependencies.

In what scenario would that be a good way to address a circular
dependency? ISTM that whatever depends on $ext should be using shell
types or such to avoid the circular dependency, then create $ext. Rather
than creating shell types for object in $ext and then create $ext.


> Another point that perhaps deserves discussion is whether it's
> okay to change the signature of GenerateTypeDependencies in
> stable branches (we need to fix this in v13 not only v14/HEAD).
> I can't see a good reason for extensions to be calling that,
> and codesearch.debian.net knows of no outside callers, so I'm
> inclined to just change it.  If anyone thinks that's too risky,
> we could do something with a wrapper function in v13.

Seems OK to not bother with a wrapper to me - I can't see a reason
either.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c)
Next
From: Justin Pryzby
Date:
Subject: Re: Autovacuum on partitioned table (autoanalyze)