* Peter Eisentraut ([EMAIL PROTECTED]) wrote: > Stephen Frost wrote: > > Is there a particular issue/problem you're running into? It might > > make more sense to focus on what you actually need than what the spec > > says you need... > > The particular issue I'm running into is that I'm trying to get the > information schema up to speed but the current role implementation > doesn't really match anywhere. I remember the discussion about the > inherit flag vaguely, and I think I might even have contributed to the > confusion, but the fact is that some concepts like the purpose of SET > ROLE and the difference between enabled and applicable roles have > apparently been misunderstood.
Well.. Applicable roles are roles which you can "SET ROLE" to, but
which you don't automatically get the permissions of (inherit). As I
recall, the spec wants all roles to be like this until an explicit "SET
ROLE" is done. When a "SET ROLE" is done, then that role (and all other
roles granted to it) are "enabled".
In Postgres terms, the "pg_has_role()" function can provide the answer
to both questions, based on what's passed in.
For 'enabled' roles:
pg_has_role('abc','USAGE');
For 'applicable' roles:
pg_has_role('abc','MEMBER');
Where the current user is asking the question "do I have USAGE/MEMBER
(enabled/applicable) rights on role 'abc'?"
At least, I'm pretty sure that's the idea. Hopefully that helps clear
up what should be done in information_schema...
Thanks,
Stephen
signature.asc
Description: Digital signature
