Re: Granting SET and ALTER SYSTE privileges for GUCs
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>,
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>,
Joshua Brindle <joshua.brindle@crunchydata.com>,
Robert Haas <robertmhaas@gmail.com>, Jeff Davis <pgsql@j-davis.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>,
Joe Conway <joe@crunchydata.com>
Date: 2022-03-17T15:41:38Z
Lists: pgsql-hackers
On 3/17/22 10:47, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
>> On 16.03.22 19:47, Tom Lane wrote:
>>> ... Perhaps we could just use "SET" and
>>> "ALTER", or "SET" and "SYSTEM"?
>> I think Oracle and MS SQL Server have many multi-word privilege names.
>> So users are quite used to that. And if we want to add more complex
>> privileges, we might run out of sensible single words eventually. So I
>> would not exclude this approach.
> 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.
>
>
The upside of this is that it avoids the inelegant
GRANT SET ON SETTING ...
But I was just looking again at the grammar, and the only reason we need
this keyword at all AFAICS is to disambiguate ALL [PRIVILEGES] cases.
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.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Commits
-
Allow granting SET and ALTER SYSTEM privileges on GUC parameters.
- a0ffa885e478 15.0 landed