Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s4r8G-001TCw-QG for pgsql-bugs@arkaria.postgresql.org; Wed, 08 May 2024 23:55:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s4r8E-003XNF-SQ for pgsql-bugs@arkaria.postgresql.org; Wed, 08 May 2024 23:55:31 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s4r8E-003XMy-KC for pgsql-bugs@lists.postgresql.org; Wed, 08 May 2024 23:55:30 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s4r85-0005hs-41 for pgsql-bugs@lists.postgresql.org; Wed, 08 May 2024 23:55:29 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 448NtJEB950008; Wed, 8 May 2024 19:55:19 -0400 From: Tom Lane To: "David G. Johnston" cc: PostgreSQL Bug List Subject: Re: Upgrading an extension's extnamespace from user-specified to a defined schema breaks dump/restore In-reply-to: References: <935496.1715207399@sss.pgh.pa.us> Comments: In-reply-to "David G. Johnston" message dated "Wed, 08 May 2024 16:12:47 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <950006.1715212519.1@sss.pgh.pa.us> Date: Wed, 08 May 2024 19:55:19 -0400 Message-ID: <950007.1715212519@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "David G. Johnston" writes: > Let me simplify this a bit. But the parameter "relocatable" has nothing to > do with this, "schema" does. > =========================== >> cat testext.control > comment = 'testing extension' > default_version = '1.0' > relocatable = false > trusted = false >> cat testext--1.1.control > schema=pg_control So the actual situation with pg_cron is that they've *never* been relocatable, but now they want to bind a particular schema where before they let the user choose? I absolutely won't accept a suggestion that we should allow ALTER SET SCHEMA if the extension is saying it's not relocatable. Potentially breaking other non-relocatable extensions is not an okay tradeoff for coping with an extremely questionable decision on pg_cron's part. I'm also not really inclined to assume that even if we let SET SCHEMA happen, it would successfully move such an extension. I think a reasonable penalty on pg_cron for this is that they should have to supply an extension upgrade script that does per-object ALTER XXX SET SCHEMA to get everything (or at least as much as they want) into the newly selected schema. I do see a missing bit, which is that if the new control file says schema = whatever, we should probably update extnamespace to match --- which I guess was your point as well. But I don't want to take responsibility for making the member objects match that. regards, tom lane