Re: Additional role attributes && superuser review

* 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.

Thanks for trying to make progress on this.

> 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:

For my 2c- I don't think we'd be able to drop the old syntax and
therefore I'm not sure that I really see the point in adding new syntax.
I don't hold that position strongly, but I don't like the idea that
we're just going to be sitting on our thumbs because we can't agree on
the color of the bike shed.

If there is agreement to move forward with using the syntax below,
great, that can be implemented in relatively short order. If there
isn't, then let's move forward with the existing syntax and change it
later, if there is agreement to do so at some point in the future.

I don't like the idea of tying it into GRANT. GRANT is SQL-spec
defined, quite overloaded already, and role attributes don't act like
GRANTs anyway (there's no ADMIN option and they aren't inheirited).

> 2. Catalog Representation:
>
> Condense all attributes in pg_authid to single int64 column and create
> bitmasks accordingly.

I'd suggest we do this regardless and the only question is if we feel
there is need to provide a view to split them back out again or not.
I'm inclined to say 'no' to another view and instead suggest we provide
SQL-level "has_whatever_privilege" for these which match the existing C
functions, update our clients to use those, and encourage others to do
the same. Probably also helpful would be a single function that returns
a simple list of the non-default role attributes which a user has and
we'd simplify psql's describeRoles by having it use that instead.

> 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?

I agree that doing these changes at the same time makes sense, if we can
get agreement on what exactly to do. I've shared my thoughts, but we
really need input from others, ideally of the form of "I prefer X over
Y" rather than "well, we could do X or Y".

Thanks!

Stephen