diff options
Diffstat (limited to 'doc/src/sgml/ref')
| -rw-r--r-- | doc/src/sgml/ref/grant.sgml | 25 | ||||
| -rw-r--r-- | doc/src/sgml/ref/revoke.sgml | 27 |
2 files changed, 50 insertions, 2 deletions
diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml index 8e8196f480d..bb9571abd83 100644 --- a/doc/src/sgml/ref/grant.sgml +++ b/doc/src/sgml/ref/grant.sgml @@ -1,5 +1,5 @@ <!-- -$PostgreSQL: pgsql/doc/src/sgml/ref/grant.sgml,v 1.49 2005/10/13 23:26:00 tgl Exp $ +$PostgreSQL: pgsql/doc/src/sgml/ref/grant.sgml,v 1.50 2005/10/20 19:18:01 tgl Exp $ PostgreSQL documentation --> @@ -344,6 +344,29 @@ GRANT <replaceable class="PARAMETER">role</replaceable> [, ...] </para> <para> + <command>GRANT</> and <command>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 + <literal>WITH GRANT OPTION</literal> on the object. In this case the + privileges will be recorded as having been granted by the role that + actually owns the object or holds the privileges + <literal>WITH GRANT OPTION</literal>. For example, if table + <literal>t1</> is owned by role <literal>g1</>, of which role + <literal>u1</> is a member, then <literal>u1</> can grant privileges + on <literal>t1</> to <literal>u2</>, but those privileges will appear + to have been granted directly by <literal>g1</>. Any other member + of role <literal>g1</> could revoke them later. + </para> + + <para> + If the role executing <command>GRANT</> holds the required privileges + indirectly via more than one role membership path, it is unspecified + which containing role will be recorded as having done the grant. In such + cases it is best practice to use <command>SET ROLE</> to become the + specific role you want to do the <command>GRANT</> as. + </para> + + <para> Currently, <productname>PostgreSQL</productname> does not support granting or revoking privileges for individual columns of a table. One possible workaround is to create a view having just the desired 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 @@ <!-- -$PostgreSQL: pgsql/doc/src/sgml/ref/revoke.sgml,v 1.34 2005/07/26 23:24:02 tgl Exp $ +$PostgreSQL: pgsql/doc/src/sgml/ref/revoke.sgml,v 1.35 2005/10/20 19:18:01 tgl Exp $ PostgreSQL documentation --> @@ -158,6 +158,31 @@ REVOKE [ ADMIN OPTION FOR ] it is possible for a superuser to revoke all privileges, but this may require use of <literal>CASCADE</literal> as stated above. </para> + + <para> + <command>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 + <literal>WITH GRANT OPTION</literal> 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 + <literal>WITH GRANT OPTION</literal>. For example, if table + <literal>t1</> is owned by role <literal>g1</>, of which role + <literal>u1</> is a member, then <literal>u1</> can revoke privileges + on <literal>t1</> that are recorded as being granted by <literal>g1</>. + This would include grants made by <literal>u1</> as well as by other + members of role <literal>g1</>. + </para> + + <para> + If the role executing <command>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 <command>SET ROLE</> to become the specific + role you want to do the <command>REVOKE</> as. Failure to do so may + lead to revoking privileges other than the ones you intended, or not + revoking anything at all. + </para> </refsect1> <refsect1 id="SQL-REVOKE-examples"> |