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

Re: [PATCHES] Roles - SET ROLE Updated

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] Roles - SET ROLE Updated
Date: 2005-07-26 16:44:57
Message-ID: 16516.1122396297@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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

In response to

Responses

pgsql-hackers by date

Next:From: Stephen FrostDate: 2005-07-26 16:52:11
Subject: Re: [PATCHES] Roles - SET ROLE Updated
Previous:From: Matthew T. O'ConnorDate: 2005-07-26 15:45:19
Subject: Re: [HACKERS] Autovacuum loose ends

pgsql-patches by date

Next:From: Stephen FrostDate: 2005-07-26 16:52:11
Subject: Re: [PATCHES] Roles - SET ROLE Updated
Previous:From: Matthew T. O'ConnorDate: 2005-07-26 15:45:19
Subject: Re: [HACKERS] Autovacuum loose ends

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