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: https://postgr.es/m/504497aca66bf34bdcdd90bd0bcebdc3a33f577b[email protected]

diff --git a/doc/src/sgml/ddl.sgml b/doc/src/sgml/ddl.sgml
index 9d6ec2c7382eabecf63573cca1d5854b8566b75c..0be0774748955392c0fd9ea5b5d2d54d91297471 100644 (file)
--- a/doc/src/sgml/ddl.sgml
+++ b/doc/src/sgml/ddl.sgml
@@ -1578,8 +1578,10 @@ ALTER TABLE products RENAME TO items;
   
 
   
-   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 .)
   
 
   
@@ -1614,17 +1616,11 @@ GRANT UPDATE ON accounts TO joe;
   
 
   
-   To revoke a privilege, use the fittingly named
+   To revoke a previously-granted privilege, use the fittingly named
     command:
 
 REVOKE ALL ON accounts FROM PUBLIC;
 
-   The special privileges of the object owner (i.e., the right to do
-   DROP, GRANT, REVOKE, 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.
   
 
   
@@ -1638,6 +1634,13 @@ REVOKE ALL ON accounts FROM PUBLIC;
     reference pages.
   
 
+  
+   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.
+  
+
   
    The available privileges are:
 
@@ -4695,7 +4698,7 @@ EXPLAIN SELECT count(*) FROM measurement WHERE logdate >= DATE '2008-01-01';
    
    
   
-  
+
   
    Declarative Partitioning Best Practices