Re: Granting SET and ALTER SYSTE privileges for GUCs
От | Andrew Dunstan |
---|---|
Тема | Re: Granting SET and ALTER SYSTE privileges for GUCs |
Дата | |
Msg-id | 9b37fa41-a068-8166-78c3-4503a867de07@dunslane.net обсуждение исходный текст |
Ответ на | Re: Granting SET and ALTER SYSTE privileges for GUCs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Granting SET and ALTER SYSTE privileges for GUCs
|
Список | 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
В списке pgsql-hackers по дате отправления: