grants-are-additive.patch

diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index fb81af4..73f88e0 100644
--- a/doc/src/sgml/ref/grant.sgml
+++ b/doc/src/sgml/ref/grant.sgml
@@ -429,11 +429,27 @@ GRANT <replaceable class="PARAMETER">role_name</replaceable> [, ...] TO <replace
    </para>
 
    <para>
-    A user may perform <command>SELECT</>, <command>INSERT</>, etc. on a
-    column if he holds that privilege for either the specific column or
-    its whole table.  Granting the privilege at the table level and then
-    revoking it for one column will not do what you might wish: the
-    table-level grant is unaffected by a column-level operation.
+    Permission granted at any level of the
+    <database>database</><literal>.</><database>schema</><literal>.</><database>table</><literal>.</><database>column</>
+    object hierarchy grants permission to all contained objects.
+    E.g. a user may perform <command>SELECT</>, <command>INSERT</>,
+    etc. on a column if he holds that privilege for either the
+    specific column or its whole table.  Granting the privilege at the
+    table level and then revoking it for one column will not do what
+    you might wish: the table-level grant is unaffected by a
+    column-level operation.  Granting a privilege to some columns of a
+    table and denying the privilege to the table's other columns is
+    done in the same way as regards all other hierarchically organized
+    database objects (e.g. granting a privilege to some tables in a
+    schema and denying the privilege to the schema's other tables):
+    deny privilege to the protected columns, to their table, their
+    schema, and their database; grant privilege to the permitted
+    columns.  As <link
+    linkend="sql-grant-description-objects">described above</link>,
+    permissions granted to the roles assigned a user are likewise
+    entirely additive.  Permissions throughout
+    <productname>PostgreSQL</productname> combine in this uniform
+    fashion.
    </para>
 
    <para>