From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Additional role attributes && superuser review |
Date: | 2014-10-16 19:35:07 |
Message-ID: | CA+U5nMKoHB9cahd1sTiXOOcZNa_HwPajX-exMKQh2G6g1e-_9w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 16 October 2014 20:04, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> I'd suggest calling these capabilities, and allow:
>>>
>>> GRANT CAPABILITY whatever TO somebody;
>>
>> So, we went back to just role attributes to avoid the keyword issue..
>> The above would require making 'CAPABILITY' a reserved word, and there
>> really isn't a 'good' already-reserved word we can use there that I
>> found.
>
> Ah, good point. Using ALTER ROLE is better. Maybe we should do ALTER
> ROLE .. [ ADD | DROP ] CAPABILITY x. That would still require making
> CAPABILITY a keyword, but it could be unreserved.
I thought you had it right first time. It is mighty annoying that some
privileges are GRANTed and others ALTER ROLEd.
And we did agree earlier to call these capabilities.
How about
GRANT EXECUTE [PRIVILEGES] ON CAPABILITY foo TO bar;
That is similar to granting execution privs on a function. And I think
gets round the keyword issue?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-10-16 19:37:09 | Re: Additional role attributes && superuser review |
Previous Message | Stephen Frost | 2014-10-16 19:34:54 | Re: Additional role attributes && superuser review |