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, accountants also have all permissions + granted to employees. Unlike the fixed + table.column hierarchy the + PostgreSQL user is free to fashion roles into + arbitrary hierarchical structures.