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.

src/backend/optimizer/path/allpaths.c

@@ -1042,16 +1042,9 @@ set_subquery_pathlist(PlannerInfo *root, RelOptInfo *rel,
 			RestrictInfo *rinfo = (RestrictInfo *) lfirst(l);
 			Node	   *clause = (Node *) rinfo->clause;
 
-			/*
-			 * XXX.  You might wonder why we're testing rte->security_barrier
-			 * qual-by-qual here rather than hoisting the test up into the
-			 * surrounding if statement; after all, the answer will be the
-			 * same for all quals.  The answer is that we expect to shortly
-			 * change this logic to allow pushing down some quals that use only
-			 * "leakproof" operators even through a security barrier.
-			 */
 			if (!rinfo->pseudoconstant &&
-				!rte->security_barrier &&
+				(!rte->security_barrier ||
+				 !contain_leaky_functions(clause)) &&
 				qual_is_pushdown_safe(subquery, rti, clause, differentTypes))
 			{
 				/* Push it down */