On Thu, Oct 16, 2014 at 2:59 PM, Stephen Frost <sfrost@snowman.net> wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
>> On Thu, Oct 16, 2014 at 11:24 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>> > To me, what this repeated discussion on this particular BACKUP point
>> > says, is that the ability to run pg_start/stop_backend and the xlog
>> > related functions should be a different privilege, i.e. something other
>> > than BACKUP; because later we will want the ability to grant someone the
>> > ability to run pg_dump on the whole database without being superuser,
>> > and we will want to use the name BACKUP for that. So I'm inclined to
>> > propose something more specific for this like WAL_CONTROL or
>> > XLOG_OPERATOR, say.
>>
>> I'm a little nervous that we're going to end up with a whole bunch of
>> things with names like X_control, Y_operator, and Z_admin, which I
>> think is particularly bad if we end up with a mix of styles and also
>> bad (though less so) if we end up just tacking the word "operator"
>> onto the end of everything.
>
> Yeah, that's certainly a good point.
>
>> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company