* 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.
Also, role attributes aren't inheirited nor is there an 'ADMIN' option
for them as there is for GRANT- both of which I feel are correct for
these capabilities. Or, to say it another way, I don't think these
should have an 'ADMIN' option and I don't think they need to be
inheirited through role membership the way granted privileges are.
We could still use 'GRANT <keyword> whatever TO somebody;' without the
admin opton and without inheiritance, but I think it'd just be
confusing for users who are familiar with how GRANT works already.
Thanks!
Stephen
signature.asc
Description: Digital signature
