From c9de6b922e4f8c2647c64a67e86d4a95e3fca2cc Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Thu, 20 Oct 2005 19:18:01 +0000 Subject: Document the behavior of GRANT/REVOKE in cases where the privilege is held by means of role membership, rather than directly. Per discussion and bug fix of a couple weeks ago. --- doc/src/sgml/ref/revoke.sgml | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) (limited to 'doc/src/sgml/ref/revoke.sgml') diff --git a/doc/src/sgml/ref/revoke.sgml b/doc/src/sgml/ref/revoke.sgml index 58219c55cef..68c69f8814f 100644 --- a/doc/src/sgml/ref/revoke.sgml +++ b/doc/src/sgml/ref/revoke.sgml @@ -1,5 +1,5 @@ @@ -158,6 +158,31 @@ REVOKE [ ADMIN OPTION FOR ] it is possible for a superuser to revoke all privileges, but this may require use of CASCADE as stated above. + + + REVOKE can also be done by a role + that is not the owner of the affected object, but is a member of the role + that owns the object, or is a member of a role that holds privileges + WITH GRANT OPTION on the object. In this case the + command is performed as though it were issued by the containing role that + actually owns the object or holds the privileges + WITH GRANT OPTION. For example, if table + t1 is owned by role g1, of which role + u1 is a member, then u1 can revoke privileges + on t1 that are recorded as being granted by g1. + This would include grants made by u1 as well as by other + members of role g1. + + + + If the role executing REVOKE holds privileges + indirectly via more than one role membership path, it is unspecified + which containing role will be used to perform the command. In such cases + it is best practice to use SET ROLE to become the specific + role you want to do the REVOKE as. Failure to do so may + lead to revoking privileges other than the ones you intended, or not + revoking anything at all. + -- cgit v1.2.3