| 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: | Whole Thread | Raw Message | 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 |