On Mon, Nov 3, 2014 at 11:44 AM, Adam Brightwell
<adam.brightw...@crunchydatasolutions.com> wrote:
>> That said, I don't feel very strongly about that position, so if you and
>> Robert (and others on the thread) agree that's the right approach then
>> I'll see about getting it done.
>
> We haven't reached consensus on this one yet and I didn't want it to fall
> too far off the radar.
>
> Here is what I summarize as the current state of the discussion:
>
> 1. Syntax:
>
> ALTER ROLE <role> { ADD | DROP } CAPABILITY <capability>Seems reasonable. > * Perhaps keeping the current syntax around as deprecated to be removed in a > scheduled future version. (provide a "deprecated" message to the user?) Yeah, I don't think we should remove the existing syntax because a lot of people are used to it. We still have some very old COPY syntax around for backward-compatibility, and it's not hurting us, either. At the same time, I think recasting the existing capability-like things as capabilities per se is a good idea, because otherwise we've got this old stuff that is randomly different for no especially good reason. > GRANT EXECUTE PRIVILEGES ON <capability> TO <role> Yuck. The only other approach I can think of is have some magic, hard-coded roles that implicitly have each capability, and then those can be granted. e.g. have a role pg_unrestricted_copy or whatever with a given OID, and then test has_privs_of_role() with that OID. > Condense all attributes in pg_authid to single int64 column and create > bitmasks accordingly. > > Obviously there is some concern for upgrading and whether to do both at once > or to do them incrementally. IMHO, I think if the changes are going to be > made, then we should go ahead and do them at the same time. Though, would > it be beneficial to separate in to two distinct patches? If we're going to change the catalog representation for the existing capabilities, I'd recommend that the first patch change the catalog representation and add the new syntax without adding any more capabilities; and then the second and subsequent patches can add additional capabilities. -- 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
