On 11/14/2012 02:35:54 PM, Karl O. Pinc wrote:
> On 11/13/2012 08:50:55 PM, Peter Eisentraut wrote:
> > On Sat, 2012-09-29 at 01:16 -0500, Karl O. Pinc wrote:
> > > This patch makes some sweeping statements.
> >
> > Unfortunately, they are wrong.
>
> I will see if anything can be salvaged.
Here's another try.
(I bundled changes to both paragraphs into a single
patch.)
grants-of-roles-are-additive_v3.patch
Regards,
Karl <[email protected]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
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>
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
