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 17:43:32 |
Message-ID: | 60903644.1010105@anastigmatix.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 05/03/21 13:23, Robert Haas wrote:
> On Mon, May 3, 2021 at 11:45 AM Chapman Flack <chap(at)anastigmatix(dot)net> wrote:
>> 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).
>
> Sure, but the hook still needs a way to know which users are entitled
> to set the GUC.
I was contemplating a version 0 with only that minimal support in core
for allowing a shared preload library to set such hooks (and allowing
include-with-a-role in config files), assuming service providers already
do sophisticated building of stuff to construct the environments they
provide, and a C shared object with hooks that enforce their designed
constraints wouldn't be an onerous burden on top of that.
Such providers could then be the laboratories of democracy building
various forms of such things, and if one of those ends up having a
reasonably general configuration mechanism and gets offered as a
contrib module later or for inclusion in core, well, that's version 0.5.
Regards,
-Chap
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2021-05-03 17:51:29 | Re: function for testing that causes the backend to terminate |
Previous Message | Peter Geoghegan | 2021-05-03 17:38:37 | Re: MaxOffsetNumber for Table AMs |