On Thu, Oct 16, 2014 at 2:59 PM, Stephen Frost <sfr...@snowman.net> wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Thu, Oct 16, 2014 at 11:24 AM, Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
