Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pajVd-0005Ic-IM for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Mar 2023 20:38:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pajVc-00029i-95 for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Mar 2023 20:38:36 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pajVb-00029V-Js for pgsql-hackers@lists.postgresql.org; Fri, 10 Mar 2023 20:38:35 +0000 Received: from mail-qt1-x832.google.com ([2607:f8b0:4864:20::832]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pajVY-0005VB-LR for pgsql-hackers@lists.postgresql.org; Fri, 10 Mar 2023 20:38:34 +0000 Received: by mail-qt1-x832.google.com with SMTP id r5so7180194qtp.4 for ; Fri, 10 Mar 2023 12:38:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pcorp-us.20210112.gappssmtp.com; s=20210112; t=1678480711; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=5zBwHhdsYAs5S4zdqpmduEAo6C5ajsyaulVBT3Y1384=; b=G6oSlgVFi7wUHzK5xcLOKrNYNSDyNNWo7G/+eC9FJ15+r78vlCV5hnzZkNrMUOzNpp LctRhyJetwEoKTaq9eYrQEXEF8lNrsDOSVYsMOapPH2kRk4bsvgQ+dRUMqdFa+zr2PRX 5c9tKXRsQ+n96GMCzBFdtEKyGC90IJJePIzC/94rLpyVAPz6JX+PS/Zn8PybJfm0FJcQ xZT31apon7noBAqhSqALayQrJhbW8sac1ErQVRweRC9Dx8V7UjStaPUPN9gmG7HwOWeR ItLaN1iVNWilnpVXzGIu+zQg5cWzoibL6n1Y8MWj9vnwYU3y8hd5If+KwL/e+PVm6DmP Q+aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678480711; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5zBwHhdsYAs5S4zdqpmduEAo6C5ajsyaulVBT3Y1384=; b=gVlJCMkWpJ3Vz54RJUGDAha7i6dLEkILzR+gKYaV2ynlA9mRxsWg3A3iPC6PZi1yHW RIRFvGJdJEwMK3ErwnMQOyV/UpTM66Cjflmz9/aNGXK2ONvlFFxF29bdRVTRwKcCwSrF gnKJx146RWV88tpQWUk4qsZF8YNQX/rW/Py/NAfWSQmPkkYi1fiKXLIYlC2C9Nr1v9mb xQ0YhQ1JfXjrU4uDPteo7qy6wBbdQZWxzCfzRjVyFFf+DIY2kG7E7sRgyOZqALZYf8gT 7Ehci6eWfOue6oItlGaq/4RBRwCrHeG30fkXQFaVxxZ3ZXEg8qgG5ppEoAspqIlRY0kN n0mA== X-Gm-Message-State: AO0yUKXPFqSOr1xDXIEhsfjwF/xyXiPP4mLXr4kwGFoxH+VaJNvDh8OB 8w85fpV4Y6uyM9g6FvgcsiwaWTag1Oc4VUG66e9moQ== X-Google-Smtp-Source: AK7set8AwxUtbcKeKufWMjE4nMycl1fMi1xwFrjt75gqMc3nrB330UocMxQf3AppxiA+ZZiPvInC5g== X-Received: by 2002:a05:622a:1191:b0:3bf:a70a:8ab4 with SMTP id m17-20020a05622a119100b003bfa70a8ab4mr47840415qtk.57.1678480711564; Fri, 10 Mar 2023 12:38:31 -0800 (PST) Received: from F (50-78-240-110-static.hfc.comcastbusiness.net. [50.78.240.110]) by smtp.gmail.com with ESMTPSA id b13-20020ac87fcd000000b003ba19e53e43sm519548qtk.25.2023.03.10.12.38.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Mar 2023 12:38:31 -0800 (PST) From: "Regina Obe" To: "'Tom Lane'" Cc: "'Gregory Stark \(as CFM\)'" , "'Sandro Santilli'" , , "'Regina Obe'" References: <003001d8f4ae$402282c0$c0678840$@pcorp.us> <000401d94bc8$48dff700$da9fe500$@pcorp.us> <167762779361.628976.14009177203307564086.pgcf@coridan.postgresql.org> <005401d95083$26ca24a0$745e6de0$@pcorp.us> <995823.1678478825@sss.pgh.pa.us> In-Reply-To: <995823.1678478825@sss.pgh.pa.us> Subject: RE: Ability to reference other extensions by schema in extension scripts Date: Fri, 10 Mar 2023 15:38:25 -0500 Message-ID: <004a01d95390$43fefa40$cbfceec0$@pcorp.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFgXZxpr0yOB+9uS1Xwc1lFBKthIAFb3UkpAlqGOBEBdWkvegLXfdbzAh2KTDWvlV6e0A== Content-Language: en-us List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > -----Original Message----- > From: Tom Lane [mailto:tgl@sss.pgh.pa.us] > Sent: Friday, March 10, 2023 3:07 PM > To: Regina Obe > Cc: 'Gregory Stark (as CFM)' ; 'Sandro Santilli' > ; pgsql-hackers@lists.postgresql.org; 'Regina Obe' > > Subject: Re: Ability to reference other extensions by schema in extension > scripts > > "Regina Obe" writes: > > [ 0005-Allow-use-of-extschema-reqextname-to-reference.patch ] > > I took a look at this. I'm on board with the feature design, but not so much > with this undocumented restriction you added to ALTER EXTENSION SET > SCHEMA: > > + /* If an extension requires this extension > + * do not allow relocation */ > + if (pg_depend->deptype == DEPENDENCY_NORMAL && > pg_depend->classid == ExtensionRelationId){ > + dep.classId = pg_depend->classid; > + dep.objectId = pg_depend->objid; > + dep.objectSubId = pg_depend->objsubid; > + ereport(ERROR, > + > (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), > + errmsg("cannot SET SCHEMA of > extension %s because other extensions require it", > + NameStr(extForm- > >extname)), > + errdetail("%s requires extension %s", > + > getObjectDescription(&dep, false), > +NameStr(extForm->extname)))); > > That seems quite disastrous for usability, and it's making an assumption > unsupported by any evidence: that it will be a majority use-case for > dependent extensions to have used @extschema:myextension@ in a way that > would be broken by ALTER EXTENSION SET SCHEMA. > > I think we should just drop this. It might be worth putting in some > documentation notes about the hazard, instead. > > If you want to work harder, perhaps a reasonable way to deal with the issue > would be to allow dependent extensions to declare that they don't want your > extension relocated. But I do not think it's okay to make that the default > behavior, much less the only behavior. > And really, since we've gotten along without it so far, I'm not sure that it's > necessary to have it. > > Another thing that's bothering me a bit is the use of get_required_extension > in execute_extension_script. That does way more than you really need, and > passing a bunch of bogus parameter values to it makes me uncomfortable. > The callers already have the required extensions' OIDs at hand; it'd be better > to add that list to execute_extension_script's API instead of redoing the > lookups. > > regards, tom lane