diff --git a/doc/src/sgml/ref/create_policy.sgml b/doc/src/sgml/ref/create_policy.sgml
index 4c8c00193139600a8741b3e9a45cbebbe9873766..8ef8556b5188bc450802b8c3869c2e145b43eb8e 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>