From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Granting control of SUSET gucs to non-superusers |
Date: | 2021-05-03 15:44:57 |
Message-ID: | 60901A79.4000302@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/03/21 11:22, Robert Haas wrote:
>> The GUC system would have to expose a way for the shared object to
>> chain extra_check_hooks off existing GUCs. An extra_check_hook can check
>> both the value and the role of the caller.
>
> I think there are two parts to this problem. First, the SP needs to be
> able to delegate to some users but not others the ability to set
> superuser GUCs. Second, the SP needs to be able to control which GUCs
> the privileged users get to set and perhaps to what values. A hook of
> the type you propose here seems like it might work reasonably well for
> that second part, but it's not totally obvious to me how it helps with
> the first part.
I guess I was thinking, but forgot to convey to the keyboard, that the
existence of a non-empty extra_check_hooks chain on a SUSET GUC (which
could only have been attached from a shared preload library) would
implicitly change SUSET to mean settable whenever accepted by the hook(s).
Regards,
-Chap
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2021-05-03 15:48:52 | Re: MaxOffsetNumber for Table AMs |
Previous Message | Peter Geoghegan | 2021-05-03 15:26:28 | Re: MaxOffsetNumber for Table AMs |