From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Cc: a.kozhemyakin@postgrespro.ru
Subject: Re: ALTER TYPE vs extension membership (was Re: BUG #17144: Upgrade from v13 to v14 with the cube extension failed)
Date: Tue, 17 Aug 2021 09:35:50 -0400
Message-ID: <1075630.1629207350@sss.pgh.pa.us> (raw)
In-Reply-To: <20210817112233.tiheqcydqf4bariw@alap3.anarazel.de>
References: <17144-e67d7a8f049de9af@postgresql.org>
<895152.1629129953@sss.pgh.pa.us>
<985050.1629142619@sss.pgh.pa.us>
<20210817112233.tiheqcydqf4bariw@alap3.anarazel.de>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, pgsql-hackers@lists.postgresql.org, a.kozhemyakin@postgrespro.ru
Subject: Re: ALTER TYPE vs extension membership (was Re: BUG #17144: Upgrade from v13 to v14 with the cube extension failed)
In-Reply-To: <1075630.1629207350@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox