Skip site navigation (1) Skip section navigation (2)

Re: Role incompatibilities

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Role incompatibilities
Date: 2006-03-24 18:01:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
* Peter Eisentraut (peter_e(at)gmx(dot)net) 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:


For 'applicable' roles:


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



In response to


pgsql-hackers by date

Next:From: Stephen FrostDate: 2006-03-24 18:02:27
Subject: Re: Known but bad behavior with alter user?
Previous:From: Joshua D. DrakeDate: 2006-03-24 17:58:23
Subject: Known but bad behavior with alter user?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group