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 role_name [, ...] TO
- A user may perform SELECT>, 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.
+
+
+
+ Roles can be fashioned into a permission hierarchy. Roles having
+ the INHERIT attribute (the default) that are
+ assigned to other roles in a hierarchical fashion produce a
+ permission system which behaves in the fashion of the
+ table>.>column> hierarchy.
+ E.g. a user's login role can be assigned a role of
+ accountant> which is in turn assigned a role of
+ employee>. The user would have all the permissions of
+ an accountant> regardless of whether these permissions
+ are revoked from the employee role. And, by
+ virtue of the employee>/accountant> role
+ hierarchy, accountant>s also have all permissions
+ granted to employee>s. Unlike the fixed
+ table>.>column> hierarchy the
+ PostgreSQL> user is free to fashion roles into
+ arbitrary hierarchical structures.