Re: Add read-only param to set_config(...) / SET that effects (at least) customized runtime options

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: Matthias Kurz <m(dot)kurz(at)irregular(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add read-only param to set_config(...) / SET that effects (at least) customized runtime options
Date: 2018-04-27 15:42:00
Message-ID: 8fd0abe0-ec63-6180-e753-89a780fb78e3@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 04/20/2018 04:18 PM, Chapman Flack wrote:
> On 04/20/2018 04:03 PM, Andrew Gierth wrote:

>> Assign hooks aren't allowed to throw errors under any circumstance
>> because they're called during transaction abort, and throwing an error
>> during abort is obviously not tolerable.
>
> Ah yes, now you remind me, that was why I had put my extension idea
> on the table at the time.
>
> It seems as if, for any of these ideas (cookie-protection of GUCs
> or just SET READONLY for GUCs), at least some small patch to core
> will be prerequisite, to allow either a flag or a reset check hook
> able to make RESET skip protected GUCs.

I suppose an extension could protect a GUC of its own from reset
without the cookie, despite the lack of a reset hook in core, by
simply maintaining its own copy of the original reset value, and
stuffing the protected value into the variable's reset_val for
the duration, no?

Wouldn't be usable to protect core GUCs, but could provide an API
for other extensions to make their GUCs protectable, by passing the
config_* struct pointer to a registration function.

-Chap

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-04-27 15:44:52 Re: obsoleting plpython2u and defaulting plpythonu to plpython3u
Previous Message Tom Lane 2018-04-27 15:36:40 Re: documentation is now XML