Allow LEAKPROOF functions for better performance of security views.

We don't normally allow quals to be pushed down into a view created
with the security_barrier option, but functions without side effects
are an exception: they're OK.  This allows much better performance in
common cases, such as when using an equality operator (that might
even be indexable).

There is an outstanding issue here with the CREATE FUNCTION / ALTER
FUNCTION syntax: there's no way to use ALTER FUNCTION to unset the
leakproof flag.  But I'm committing this as-is so that it doesn't
have to be rebased again; we can fix up the grammar in a future
commit.

KaiGai Kohei, with some wordsmithing by me.

1 files changed, 14 insertions, 0 deletions

diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml
index 3038fe9adc0..59a32a8e18b 100644
--- a/doc/src/sgml/rules.sgml
+++ b/doc/src/sgml/rules.sgml
@@ -1891,6 +1891,20 @@ CREATE VIEW phone_number WITH (security_barrier) AS
 </para>
 
 <para>
+    The query planner has more flexibility when dealing with functions that
+    have no side effects.  Such functions are referred to as LEAKPROOF, and
+    include many simple, commonly used operators, such as many equality
+    operators.  The query planner can safely allow such functions to be evaluated
+    at any point in the query execution process, since invoking them on rows
+    invisible to the user will not leak any information about the unseen rows.
+    In contrast, a function that might throw an error depending on the values
+    received as arguments (such as one that throws an error in the event of
+    overflow or division by zero) are not leak-proof, and could provide
+    significant information about the unseen rows if applied before the security
+    view's row filters.
+</para>
+
+<para>
     It is important to understand that even a view created with the
     <literal>security_barrier</literal> option is intended to be secure only
     in the limited sense that the contents of the invisible tuples will not be