Stephen Frost wrote:
> You were talking about 'enabled' vs. 'applicable' roles. Above
> they're talking about 'enabled authorization identifiers' (the list
> of roles you currently have the permissions of) and 'applicable
> privileges' (the specific privileges you have as that set of roles).
According to the definition, an authorization identifier is either a
user or a role, so I don't see where the problem is.
enabled authorization identifiers -- as defined
applicable authorization identifiers -- as defined
enabled roles -- all enabled authorization identifiers that are roles
applicable roles -- all applicable authorization identifiers that are
roles
> > > For 'applicable' roles:
> > >
> > > pg_has_role('abc','MEMBER');
> >
> > What you get from this has no equivalent in the SQL standard.
>
> This doesn't apply from what you've quoted above,
The set of roles pg_has_role('abc','MEMBER') minus
pg_has_role('abc','USAGE') can only be nonempty if you define roles
with NOINHERIT, but the SQL standard doesn't provide for that. QED.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
