When a superuser does GRANT or REVOKE on an object he doesn't own,

process the command as though it were issued by the object owner.
This prevents creating weird scenarios in which the same privileges
may appear to flow from different sources, and ensures that a superuser
can in fact revoke all privileges if he wants to.  In particular this
means that the regression tests work when run by a superuser other than
the original bootstrap userid.  Per report from Larry Rosenman.

doc/src/sgml/ref/grant.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/grant.sgml,v 1.36 2003/09/20 20:12:05 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/grant.sgml,v 1.37 2003/10/31 20:00:48 tgl Exp $
 PostgreSQL documentation
 -->
 
@@ -66,19 +66,21 @@ GRANT { { CREATE | USAGE } [,...] | ALL [ PRIVILEGES ] }
   </para>
 
   <para>
-   There is no need to grant privileges to the owner of an object (usually the user that created it),
-   as the owner has all privileges by default.  (The owner could,
-   however, choose to revoke some of his own privileges for safety.)
-   The right to drop an object, or to alter it in any way is
-   not described by a grantable right; it is inherent in the owner,
-   and cannot be granted or revoked.
+   If <literal>WITH GRANT OPTION</literal> is specified, the recipient
+   of the privilege may in turn grant it to others.  By default this
+   is not allowed.  Grant options can only be granted to individual
+   users, not to groups or <literal>PUBLIC</literal>.
   </para>
 
   <para>
-   If <literal>WITH GRANT OPTION</literal> is specified, the recipient
-   of the privilege may in turn grant it to others.  By default this
-   is not possible.  Grant options can only be granted to individual
-   users, not groups or <literal>PUBLIC</literal>.
+   There is no need to grant privileges to the owner of an object
+   (usually the user that created it),
+   as the owner has all privileges by default.  (The owner could,
+   however, choose to revoke some of his own privileges for safety.)
+   The right to drop an object, or to alter its definition in any way is
+   not described by a grantable privilege; it is inherent in the owner,
+   and cannot be granted or revoked.  It is not possible for the owner's
+   grant options to be revoked, either.
   </para>
 
   <para>
@@ -263,6 +265,13 @@ GRANT { { CREATE | USAGE } [,...] | ALL [ PRIVILEGES ] }
     except when absolutely necessary.
    </para>
 
+   <para>
+    If a superuser chooses to issue a <command>GRANT</> or <command>REVOKE</>
+    command, the command is performed as though it were issued by the
+    owner of the affected object.  In particular, privileges granted via
+    such a command will appear to have been granted by the object owner.
+   </para>
+
    <para>
     Currently, to grant privileges in <productname>PostgreSQL</productname>
     to only a few columns, you must

doc/src/sgml/ref/revoke.sgml

 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/ref/revoke.sgml,v 1.27 2003/08/31 17:32:24 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/ref/revoke.sgml,v 1.28 2003/10/31 20:00:48 tgl Exp $
 PostgreSQL documentation
 -->
 
@@ -63,6 +63,11 @@ REVOKE [ GRANT OPTION FOR ]
    all users.
   </para>
 
+  <para>
+   See the description of the <xref linkend="sql-grant" endterm="sql-grant-title"> command for
+   the meaning of the privilege types.
+  </para>
+
   <para>
    Note that any particular user will have the sum
    of privileges granted directly to him, privileges granted to any group he
@@ -73,11 +78,6 @@ REVOKE [ GRANT OPTION FOR ]
    directly or via a group will still have it.
   </para>
 
-  <para>
-   See the description of the <xref linkend="sql-grant" endterm="sql-grant-title"> command for
-   the meaning of the privilege types.
-  </para>
-
   <para>
    If <literal>GRANT OPTION FOR</literal> is specified, only the grant
    option for the privilege is revoked, not the privilege itself.
@@ -116,6 +116,15 @@ REVOKE [ GRANT OPTION FOR ]
    the <literal>CASCADE</literal> option so that the privilege is
    automatically revoked from user C.
   </para>
+
+   <para>
+    If a superuser chooses to issue a <command>GRANT</> or <command>REVOKE</>
+    command, the command is performed as though it were issued by the
+    owner of the affected object.  Since all privileges ultimately come
+    from the object owner (possibly indirectly via chains of grant options),
+    it is possible for a superuser to revoke all privileges, but this may
+    require use of <literal>CASCADE</literal> as stated above.
+   </para>
  </refsect1>
 
  <refsect1 id="SQL-REVOKE-examples">
@@ -153,7 +162,8 @@ REVOKE [ GRANT OPTION FOR ] <replaceable class="PARAMETER">privileges</replaceab
     { RESTRICT | CASCADE }
 </synopsis>
     One of <literal>RESTRICT</literal> or <literal>CASCADE</literal>
-    is required.
+    is required according to the standard, but <productname>PostgreSQL</>
+    assumes <literal>RESTRICT</literal> by default.
    </para>
  </refsect1>