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

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