I've committed changes to add a "rolinherit" flag to pg_authid as per
discussion. The pg_has_role function now distinguishes USAGE rights
on a role (do you currently have the privileges of that role) from
MEMBER rights (do you have the ability to SET ROLE to that role).
A couple of loose ends remain:
* Should is_admin_of_role pay attention to rolinherit? I suspect it
should but can't quite face going through the SQL spec again to be sure.
This only affects the right to GRANT role membership to someone else.
* The information_schema needs another pass to see which pg_has_role
usages ought to be testing USAGE instead of MEMBER. I think most of
them should, but in and around applicable_roles and enabled_roles
some more thought and spec-reading is needed.
I'm planning on doing some documentation work next, and was hoping
someone else would look at the above items.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
