Re: Granting SET and ALTER SYSTE privileges for GUCs - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: Granting SET and ALTER SYSTE privileges for GUCs
Date
Msg-id 1785FFEA-77C0-4939-AB52-1A91C49B65AD@enterprisedb.com
Whole thread Raw
In response to Re: Granting SET and ALTER SYSTE privileges for GUCs  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Granting SET and ALTER SYSTE privileges for GUCs  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

> On Mar 24, 2022, at 12:06 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> On 3/24/22 12:49, Mark Dilger wrote:
>>
>>> On Mar 17, 2022, at 8:41 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
>>>
>>> If we abandoned that for this form of GRANT/REVOKE I think we could
>>> probably get away with
>>>
>>>
>>>    GRANT { SET | ALTER SYSTEM } ON setting_name ...
>>>
>>>
>>> I haven't tried it, so I could be all wrong.
>> Version 12 of the patch uses SET and ALTER SYSTEM as the names of the privileges, and PARAMETER as the name of the
thingon which the privilege is granted.  The catalog table which tracks these grants is now named pg_parameter_acl, and
variousother parts of the patch have been adjusted to use a "parameter" based, rather than a "setting" based, naming
scheme. One exception to this rule is the "setacl" column in pg_parameter_acl, which is much more compact than the
"parameteracl"name would be, so that remains under the old name. 
>
>
> I can live with it I guess, but it seems perverse to me to have
> pg_settings but pg_paramater_acl effectively referring to the same set
> of things. If we're going to do this perhaps we should create a
> pg_parameters view which is identical to pg_settings and deprecate
> pg_settings. I don;t want to hold up this patch, I think this can
> probably be managed as a follow up item.

Right, the version 12 patch was following Peter's and Tom's comments upthread:

> On Mar 17, 2022, at 7:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Well, I still say that "SET" is sufficient for the one privilege name
> (unless we really can't make Bison handle that, which I doubt).  But
> I'm willing to yield on using "ALTER SYSTEM" for the other.
>
> If we go with s/SETTING/PARAMETER/ as per your other message, then
> that would be adequately consistent with the docs I think.  So it'd
> be
>
> GRANT { SET | ALTER SYSTEM } ON PARAMETER foo TO ...
>
> and the new catalog would be pg_parameter_acl, and so on.

We could debate that again, but it seems awfully late in the development cycle.  I'd rather just get this committed,
barringany objections? 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: ExecRTCheckPerms() and many prunable partitions
Next
From: Andrew Dunstan
Date:
Subject: identifying unrecognized node type errors