Andres Freund <andres@anarazel.de> writes:
> 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.
Perhaps. But that does work today (I tested), and it's been the
intentional behavior ever since we invented extensions, to judge
by the fact that the existing comments on GenerateTypeDependencies
describe the current behavior explicitly. (Admitted, that's only
talking about types not other sorts of objects, which is why I moved
that comment in the proposed patch.) So I'm loath to get rid of it
in a back-patched bug fix.
Maybe there is a case for becoming stricter in HEAD, but I'm not
really clear on what would be an improvement. I do not think that
"don't adopt the object into the extension" could be sane. The only
other alternative is "throw an error", which goes against the clear
intention and definition of CREATE OR REPLACE.
The fact that you don't need to say CREATE OR REPLACE TYPE to replace
a shell type muddies the waters here a bit, but I think we should still
consider that behavior to be an instance of CREATE OR REPLACE.
regards, tom lane