Point out that superusers bypass privilege checking. Minor wordsmithing.

diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index 98072ee8e02ad79a9b0b0fcedfa1909dcace5c1f..6d8f193b7847e1a35d3745bd8bcf729d4dbb2814 100644 (file)
--- a/doc/src/sgml/ref/grant.sgml
+++ b/doc/src/sgml/ref/grant.sgml
@@ -1,5 +1,5 @@
 
 
@@ -43,14 +43,15 @@ GRANT { { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES | TRIGGER } [,..
   
 
   
-   Users other than the creator do not have any access privileges
-   to an object unless the creator grants permissions.
+   Users other than the creator of an object do not have any access privileges
+   to the object unless the creator grants permissions.
    There is no need to grant privileges to the creator of an object,
-   as the creator automatically holds all privileges, and can also
-   drop the object.  (The creator could, however, choose to revoke
+   as the creator automatically holds all privileges.
+   (The creator could, however, choose to revoke
    some of his own privileges for safety.  Note that the ability to
    grant and revoke privileges is inherent in the creator and cannot
-   be lost.)
+   be lost.  The right to drop the object is likewise inherent in the
+   creator, and cannot be granted or revoked.)
   
 
   
@@ -96,7 +97,7 @@ GRANT { { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES | TRIGGER } [,..
      DELETE
      
       
-       Allows the  of a row from the
+       Allows  of a row from the
        specified table.
       
      
@@ -107,7 +108,7 @@ GRANT { { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES | TRIGGER } [,..
      
       
        Allows the creation of a rule on the table/view.  (See 
-       linkend="sql-createrule" endterm="sql-createrule-title"> statement).
+       linkend="sql-createrule" endterm="sql-createrule-title"> statement.)
       
      
     
@@ -117,7 +118,7 @@ GRANT { { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES | TRIGGER } [,..
      
       
        To create a table with a foreign key constraint, it is
-       necessary to have this privilege on the table with the primary
+       necessary to have this privilege on the table with the referenced
        key.
       
      
@@ -128,7 +129,7 @@ GRANT { { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES | TRIGGER } [,..
      
       
        Allows the creation of a trigger on the specified table.  (See
-        statement).
+        statement.)
       
      
     
@@ -138,7 +139,8 @@ GRANT { { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES | TRIGGER } [,..
      
       
        Grant all of the above privileges at once.  The
-       PRIVILEGES key word is optional, but it is
+       PRIVILEGES key word is optional in
+       PostgreSQL, though it is
        required by strict SQL.
       
      
@@ -154,6 +156,14 @@ GRANT { { SELECT | INSERT | UPDATE | DELETE | RULE | REFERENCES | TRIGGER } [,..
  
   Notes
 
+   
+    It should be noted that database superusers can access
+    all objects regardless of object privilege settings.  This
+    is comparable to the rights of root in a Unix system.
+    As with root, it's unwise to operate as a superuser
+    except when absolutely necessary.
+   
+
    
     Currently, to grant privileges in PostgreSQL
     to only a few columns, you must