Hi,
The attached documentation patch further describes the
additive nature of the permission system.
This patch makes some sweeping statements. It needs
review by someone who knows whats in all the corners.
(I'm sure this would happen anyway, but it seems worth
mentioning.)
Paragraph structure is:
Describe permission semantics. Provide example of a common
error (unchanged from pre-existing text.) Generalize from
the example's lesson and provide correct process. Show
the semantics apply uniformly throughout Postgres.
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..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>
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
