From d6314b20cd872a542d71738df54a906d2962abb8 Mon Sep 17 00:00:00 2001 From: Joe Conway Date: Thu, 30 Jul 2015 10:16:36 -0700 Subject: [PATCH] Improve CREATE FUNCTION doc WRT to LEAKPROOF RLS interaction. Patch by Dean Rasheed. Back-patched to 9.5 where RLS was introduced. --- doc/src/sgml/ref/create_function.sgml | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) 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. -- 2.40.0