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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2005-07-26 16:52:11 | Re: [PATCHES] Roles - SET ROLE Updated |
Previous Message | Matthew T. O'Connor | 2005-07-26 15:45:19 | Re: [HACKERS] Autovacuum loose ends |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2005-07-26 16:52:11 | Re: [PATCHES] Roles - SET ROLE Updated |
Previous Message | Matthew T. O'Connor | 2005-07-26 15:45:19 | Re: [HACKERS] Autovacuum loose ends |