Stephen Frost <[EMAIL PROTECTED]> writes:
> Here's the results of this. I think we're pretty close to having both
> "Basic roles" and "Extended roles" personally. For 'Basic roles' we
> need SET ROLE and some information schema tables.
The information schema views already exist, although I suspect the view
definitions may need more work.
> For 'Extended roles'
> I think we need '<default option> CURRENT_ROLE' (if this isn't already
> taken care of because CURRENT_ROLE is a function?),
Yes, it is.
> REVOKE ROLE w/CASCADE drop behavior.
I was just about to quiz you about the lack of any use of the grantor
column in pg_auth_members. I suppose that revoking a membership that
was held WITH ADMIN OPTION ought to lead to searching for and destroying
all memberships granted by that ID (possibly indirectly?). DROP ROLE
has got the same problem.
Also, I've been working on converting the CREATEROLE privilege into
something usable, and am about ready to commit that. The way it works
is that CREATEROLE lets you do anything that user.c formerly required
superuser for, *except* that you have to be superuser to mess with
superuser roles in any way. This all seems fine as far as it goes,
but should revoking CREATEROLE lead to dropping grants that were made
by means of that power? Not sure. We ended up with some fairly
carefully crafted compromises for ACL representation of grants made
by superusers, and I think we'll likely need to think hard about it
for role memberships too.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
