From 39f2594ba54657f3fa8d0fe230447e673bcba2a4 Mon Sep 17 00:00:00 2001 From: Robert Haas <rhaas@postgresql.org> Date: Wed, 7 Jan 2015 14:49:59 -0500 Subject: [PATCH] docs: Reword CREATE POLICY documentation. --- doc/src/sgml/ref/create_policy.sgml | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/ref/create_policy.sgml b/doc/src/sgml/ref/create_policy.sgml index 4c8c0019313..8ef8556b518 100644 --- a/doc/src/sgml/ref/create_policy.sgml +++ b/doc/src/sgml/ref/create_policy.sgml @@ -39,16 +39,18 @@ CREATE POLICY <replaceable class="parameter">name</replaceable> ON <replaceable </para> <para> - A policy is an expression which is added to the security-barrier - qualifications of queries which are run against the table the policy is on, - or an expression which is added to the with-check options for a table and - which is applied to rows which would be added to the table. - The security-barrier qualifications will always be evaluated prior to any - user-defined functions or user-provided WHERE clauses, while the with-check - expression will be evaluated against the rows which are going to be added to - the table. By adding policies to a table, a user can limit the rows which a - given user can select, insert, update, or delete. This capability is also - known as Row Level Security or RLS. + A policy limits the ability to SELECT, INSERT, UPDATE, or DELETE rows + in a table to those rows which match the relevant policy expression. + Existing table rows are checked against the expression specified via + USING, while new rows that would be created via INSERT or UPDATE are + checked against the expression specified via WITH CHECK. Generally, + the system will enforce filter conditions imposed using security + policies prior to qualifications that appear in the query itself, in + order to the prevent the inadvertent exposure of the protected data to + user-defined functions which might not be trustworthy. However, + functions and operators marked by the system (or the system + administrator) as LEAKPROOF may be evaluated before policy + expressions, as they are assumed to be trustworthy. </para> <para> -- GitLab