From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [PATCHES] Roles - SET ROLE Updated |
Date: | 2005-07-21 21:45:14 |
Message-ID: | 20050721214514.GL24207@ns.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
* Stephen Frost (sfrost(at)snowman(dot)net) wrote:
> Doing this doesn't seem entirely unreasonable but we don't currently
> have a way of handling 'SET ROLE none;'. We'd need to make some changes
> but I think we could handle it, and correctly handle a specific
> 'SET ROLE <role>', which under Oracle does appear to drop any other
> roles you currently have.
Thinking about this a bit more.. Basically what we have is:
An implicit 'SET ROLE all;' on session connect, like Oracle does.
Support from the patch for an explicit 'SET ROLE <role>;', which drops
privileges for all other roles except the role set. The only change to
correctly support that would be to add 'CURRENT_USER' back into the
resulting set of 'enabled_roles' (but not doing so recursively or we're
back to 'SET ROLE all;'). You don't appear to be able to drop rights
which you have via CURRENT_USER.
To support having certain roles turned on and certain roles turned off
would be some additional effort. I think we'd need a list of
'ENABLED_ROLES' and then correct recursion based off of that list
instead of just starting from a single point like we do now.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Ron Mayer | 2005-07-21 22:01:23 | Re: Imprecision of DAYS_PER_MONTH |
Previous Message | Stephen Frost | 2005-07-21 21:38:10 | Re: [PATCHES] Roles - SET ROLE Updated |
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Wong | 2005-07-21 21:55:07 | Re: COPY FROM performance improvements |
Previous Message | Stephen Frost | 2005-07-21 21:38:10 | Re: [PATCHES] Roles - SET ROLE Updated |