grants-of-roles-are-additive_v3.patch

diff --git a/doc/src/sgml/ref/grant.sgml b/doc/src/sgml/ref/grant.sgml
index fb81af4..b57000c 100644
--- a/doc/src/sgml/ref/grant.sgml
+++ b/doc/src/sgml/ref/grant.sgml
@@ -429,11 +429,32 @@ 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
+    Permission granted to a table grants permission to all the columns
+    of a table, regardless of permissions granted to the table's
+    columns.  Granting a 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.
+    table-level grant is unaffected by a column-level operation.  But
+    revoking permission at the table level and granting it at the
+    column level does grant permission to the column.
+   </para>
+
+   <para>
+    Roles can be fashioned into a permission hierarchy.  Roles having
+    the <literal>INHERIT</literal> attribute (the default) that are
+    assigned to other roles in a hierarchical fashion produce a
+    permission system which behaves in the fashion of the
+    <database>table</><literal>.</><database>column</> hierarchy.
+    E.g. a user's login role can be assigned a role of
+    <literal>accountant</> which is in turn assigned a role of
+    <literal>employee</>.  The user would have all the permissions of
+    an <literal>accountant</> regardless of whether these permissions
+    are revoked from the <literal>employee</literal> role.  And, by
+    virtue of the <literal>employee</>/<literal>accountant</> role
+    hierarchy, <literal>accountant</>s also have all permissions
+    granted to <literal>employee</>s.  Unlike the fixed
+    <database>table</><literal>.</><database>column</> hierarchy the
+    <productname>PostgreSQL</> user is free to fashion roles into
+    arbitrary hierarchical structures.
    </para>
 
    <para>