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

Поиск
Список
Период
Сортировка
От Laurenz Albe
Тема Re: BUG #18964: `ALTER DATABASE ... RESET ...` fails to reset extension parameters that no longer exist
Дата
Msg-id 803ddef427b9016be04af9320925e9570d3fcc06.camel@cybertec.at
обсуждение исходный текст
Ответ на Re: BUG #18964: `ALTER DATABASE ... RESET ...` fails to reset extension parameters that no longer exist  (Nathan Bossart <nathandbossart@gmail.com>)
Ответы Re: BUG #18964: `ALTER DATABASE ... RESET ...` fails to reset extension parameters that no longer exist
Список pgsql-bugs
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



В списке pgsql-bugs по дате отправления: