From: Joe Conway Date: Thu, 30 Jul 2015 17:16:36 +0000 (-0700) Subject: Improve CREATE FUNCTION doc WRT to LEAKPROOF RLS interaction. X-Git-Tag: REL9_6_BETA1~1583 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=d6314b20cd872a542d71738df54a906d2962abb8;p=postgresql Improve CREATE FUNCTION doc WRT to LEAKPROOF RLS interaction. Patch by Dean Rasheed. Back-patched to 9.5 where RLS was introduced. --- diff --git a/doc/src/sgml/ref/create_function.sgml b/doc/src/sgml/ref/create_function.sgml index c5beb166cf..cc2098c442 100644 --- 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 - security_barrier option. See + values in any error message, is not leakproof. This affects how the + system executes queries against views created with the + security_barrier 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 and . This option can only be set by the superuser.