I think the docs for the LEAKPROOF option in create_function.sgml
ought to mention RLS as well as security barrier views. Also the
current text is no longer strictly correct in light of commit
dcbf5948e12aa60b4d6ab65b6445897dfc971e01. Suggested rewording
attached.

Regards,
Dean
diff --git a/doc/src/sgml/ref/create_function.sgml b/doc/src/sgml/ref/create_function.sgml
new file mode 100644
index c5beb16..cc2098c
--- a/doc/src/sgml/ref/create_function.sgml
+++ b/doc/src/sgml/ref/create_function.sgml
@@ -350,9 +350,18 @@ CREATE [ OR REPLACE ] FUNCTION
        effects.  It reveals no information about its arguments other than by
        its return value.  For example, a function which throws an error message
        for some argument values but not others, or which includes the argument
-       values in any error message, is not leakproof.   The query planner may
-       push leakproof functions (but not others) into views created with the
-       <literal>security_barrier</literal> option.  See
+       values in any error message, is not leakproof.  This affects how the
+       system executes queries against views created with the
+       <literal>security_barrier</literal> option or tables with row level
+       security enabled.  The system will enforce conditions from security
+       policies and security barrier views before any user-supplied conditions
+       from the query itself that contain non-leakproof functions, in order to
+       prevent the inadvertent exposure of data.  Functions and operators
+       marked as leakproof are assumed to be trustworthy, and may be executed
+       before conditions from security policies and security barrier views.
+       In addtion, functions which do not take arguments or which are not
+       passed any arguments from the security barrier view or table do not have
+       to be marked as leakproof to be executed before security conditions.  See
        <xref linkend="sql-createview"> and <xref linkend="rules-privileges">.
        This option can only be set by the superuser.
       </para>
-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to