Add a security_barrier option for views.

When a view is marked as a security barrier, it will not be pulled up
into the containing query, and no quals will be pushed down into it,
so that no function or operator chosen by the user can be applied to
rows not exposed by the view.  Views not configured with this
option cannot provide robust row-level security, but will perform far
better.

Patch by KaiGai Kohei; original problem report by Heikki Linnakangas
(in October 2009!).  Review (in earlier versions) by Noah Misch and
others.  Design advice by Tom Lane and myself.  Further review and
cleanup by me.

src/backend/optimizer/path/allpaths.c

@@ -744,6 +744,11 @@ set_subquery_pathlist(PlannerInfo *root, RelOptInfo *rel,
 	 * pseudoconstant clauses; better to have the gating node above the
 	 * subquery.
 	 *
+	 * Also, if the sub-query has "security_barrier" flag, it means the
+	 * sub-query originated from a view that must enforce row-level security.
+	 * We must not push down quals in order to avoid information leaks, either
+	 * via side-effects or error output.
+	 *
 	 * Non-pushed-down clauses will get evaluated as qpquals of the
 	 * SubqueryScan node.
 	 *
@@ -762,7 +767,16 @@ 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 &&
 				qual_is_pushdown_safe(subquery, rti, clause, differentTypes))
 			{
 				/* Push it down */