Re: BUG #18964: `ALTER DATABASE ... RESET ...` fails to reset extension parameters that no longer exist

On Wed, 2025-06-25 at 11:06 -0500, Nathan Bossart wrote:
> 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...

I tested your patch, and it works as expected for

ALTER DATABASE ... RESET
ALTER ROLE ... RESET
ALTER ROLE ... IN DATABASE ... RESET

There is still one piece missing in my opinion:

ALTER SYSTEM RESET testext.swap_limit;
ERROR: invalid configuration parameter name "testext.swap_limit"
DETAIL: "testext" is a reserved prefix.

I think that this case should work like the others.

I'd like to see regression tests for this, but I am not sure how
to best devise them.
One idea would be to stick them into the regression tests of some
contrib module, even though it is not the perfect place.
Perhaps a sequence like this:

DO $$BEGIN EXECUTE format(
'ALTER DATABASE %I SET pg_trgm.somevar = 42',
current_catalog); END$$;

LOAD 'pg_trgm';
WARNING: invalid configuration parameter name "pg_trgm.somevar", removing it
DETAIL: "pg_trgm" is now a reserved prefix.

DO $$BEGIN EXECUTE format(
'ALTER DATABASE %I RESET pg_trgm.somevar',
current_catalog); END$$;

\drds

> 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

I have no strong opinion about that.
I'd say it is good enough to allow superusers to reset such parameters.

Yours,
Laurenz Albe