Date: Wed, 25 Jun 2025 11:06:05 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: mert@futo.org, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18964: `ALTER DATABASE ... RESET ...` fails to reset
 extension parameters that no longer exist
Message-ID: <aFwebUErRdEKZy6i@nathan>
References: <18964-ba09dea8c98fccd6@postgresql.org>
 <aFW8R6Qlgtbp7TOk@nathan>
 <2474668.1750451081@sss.pgh.pa.us>
 <aFXQmZ2sveFAwdjY@nathan>
 <aFXlRTxMxVyMjfjq@nathan>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="tHVdw3fiIHnjo3EY"
Content-Disposition: inline
In-Reply-To: <aFXlRTxMxVyMjfjq@nathan>
Archived-At: <https://www.postgresql.org/message-id/aFwebUErRdEKZy6i%40nathan>
Precedence: bulk


--tHVdw3fiIHnjo3EY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Here is a tidied-up version of the patch.  It's still quite fragile, but
AFAICT to do any better we'd need to return more context from
find_option(), and I don't think we can change that one on the
back-branches since it's exported.  I assume we don't want find_option() to
create a placeholder in this case, either.  I'll continue to look around
for a better solution...

If we wanted to open up RESET in this case to everyone with suitable
privileges on the target DB and/or role (as proposed by Tom upthread [0]),
I think we'd just need to replace the "return false;" under find_option()
to "return reset_custom;".

[0] https://postgr.es/m/2474668.1750451081%40sss.pgh.pa.us

-- 
nathan

--tHVdw3fiIHnjo3EY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
	filename=v2-0001-Allow-resetting-unknown-custom-GUCs-with-reserved.patch