Doc: improve discussion of object owners' inherent privileges.
In particular, clarify that the role membership mechanism allows
members to inherit the ownership privileges of an object's owning
role.
Laurenz Albe, with some kibitzing by me
Discussion:
@@ -1578,8 +1578,10 @@ ALTER TABLE products RENAME TO items;
</para>
<para>
- The right to modify or destroy an object is always the privilege of
- the owner only.
+ The right to modify or destroy an object is inherent in being the
+ object's owner, and cannot be granted or revoked in itself.
+ (However, like all privileges, that right can be inherited by
+ members of the owning role; see <xref linkend="role-membership"/>.)
</para>
<para>
@@ -1614,17 +1616,11 @@ GRANT UPDATE ON accounts TO joe;
</para>
<para>
- To revoke a privilege, use the fittingly named
+ To revoke a previously-granted privilege, use the fittingly named
<xref linkend="sql-revoke"/> command:
<programlisting>
REVOKE ALL ON accounts FROM PUBLIC;
</programlisting>
- The special privileges of the object owner (i.e., the right to do
- <command>DROP</command>, <command>GRANT</command>, <command>REVOKE</command>, etc.)
- are always implicit in being the owner,
- and cannot be granted or revoked. But the object owner can choose
- to revoke their own ordinary privileges, for example to make a
- table read-only for themselves as well as others.
</para>
<para>
@@ -1638,6 +1634,13 @@ REVOKE ALL ON accounts FROM PUBLIC;
<xref linkend="sql-revoke"/> reference pages.
</para>
+ <para>
+ An object's owner can choose to revoke their own ordinary privileges,
+ for example to make a table read-only for themselves as well as others.
+ But owners are always treated as holding all grant options, so they
+ can always re-grant their own privileges.
+ </para>
+
<para>
The available privileges are:
