From af019fb9aec0274875a10a89c68c8fecb949349f Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Tue, 26 Jul 2005 16:38:29 +0000 Subject: Add a role property 'rolinherit' which, when false, denotes that the role doesn't automatically inherit the privileges of roles it is a member of; for such a role, membership in another role can be exploited only by doing explicit SET ROLE. The default inherit setting is TRUE, so by default the behavior doesn't change, but creating a user with NOINHERIT gives closer adherence to our current reading of SQL99. Documentation still lacking, and I think the information schema needs another look. --- doc/src/sgml/catalogs.sgml | 30 +++++++++++++++++++++++++++++- doc/src/sgml/func.sgml | 9 +++++++-- 2 files changed, 36 insertions(+), 3 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index fa0abca950c..0c8ed68195d 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -1,6 +1,6 @@ @@ -976,6 +976,14 @@ Role has superuser privileges + + rolinherit + bool + + Role automatically inherits privileges of roles it is a + member of + + rolcreaterole bool @@ -4728,6 +4736,11 @@ that blanks out the password field. + + This view explicitly exposes the OID column of the underlying table, + since that is needed to do joins to other catalogs. + + <structname>pg_roles</> Columns @@ -4756,6 +4769,14 @@ Role has superuser privileges + + rolinherit + bool + + Role automatically inherits privileges of roles it is a + member of + + rolcreaterole bool @@ -4811,6 +4832,13 @@ Session defaults for run-time configuration variables + + + oid + oid + pg_authid.oid + ID of role +
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index b5ce30105bc..0fdcb1d0df1 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -1,5 +1,5 @@ @@ -8559,7 +8559,12 @@ SELECT has_function_privilege('joeuser', 'myfunc(int, text)', 'execute'); can access a role in a particular way. The possibilities for its arguments are analogous to has_table_privilege. The desired access privilege type must evaluate to - MEMBER. + MEMBER or + USAGE. + MEMBER denotes direct or indirect membership in + the role (that is, the right to do SET ROLE), while + USAGE denotes whether the privileges of the role + are immediately available without doing SET ROLE. -- cgit v1.2.3