Add a note about the difference between Postgres' treatment of the rights

of an object owner and the SQL spec's treatment of these rights.

diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index 9ea480c57a32aafb783514e025860ecf3d22d43a..d6a6ef94b6f0b73427c8961c2a73f85b09ab5377 100644 (file)
--- 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.42 2004/08/07 20:44:50 tgl Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/grant.sgml,v 1.43 2004/09/01 04:13:11 tgl Exp $
 PostgreSQL documentation
 -->
 
@@ -403,6 +403,18 @@ GRANT ALL PRIVILEGES ON kinds TO manuel;
     one object per command.
    </para>
 
+   <para>
+    <productname>PostgreSQL</productname> allows an object owner to revoke his
+    own ordinary privileges: for example, a table owner can make the table
+    read-only to himself by revoking his own INSERT, UPDATE, and DELETE
+    privileges.  This is not possible according to the SQL standard.  The
+    reason is that <productname>PostgreSQL</productname> treats the owner's
+    privileges as having been granted by the owner to himself; therefore he
+    can revoke them too.  In the SQL standard, the owner's privileges are
+    granted by an assumed entity <quote>_SYSTEM</>.  Not being
+    <quote>_SYSTEM</>, the owner cannot revoke these rights.
+   </para>
+
    <para>
     The SQL standard allows setting privileges for individual columns
     within a table: