Re: Additional role attributes && superuser review

On Mon, Nov 3, 2014 at 11:44 AM, Adam Brightwell
<adam(dot)brightwell(at)crunchydatasolutions(dot)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