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.

1 files changed, 13 insertions, 0 deletions

diff --git a/src/backend/utils/adt/selfuncs.c b/src/backend/utils/adt/selfuncs.c
index abef8abc382..bb411f9ad1d 100644
--- a/src/backend/utils/adt/selfuncs.c
+++ b/src/backend/utils/adt/selfuncs.c
@@ -4373,6 +4373,19 @@ examine_simple_variable(PlannerInfo *root, Var *var,
 			return;
 
 		/*
+		 * If the sub-query originated from a view with the security_barrier
+		 * attribute, we treat it as a black-box from outside of the view.
+		 * This is probably a harsher restriction than necessary; it's
+		 * certainly OK for the selectivity estimator (which is a C function,
+		 * and therefore omnipotent anyway) to look at the statistics.  But
+		 * many selectivity estimators will happily *invoke the operator
+		 * function* to try to work out a good estimate - and that's not OK.
+		 * So for now, we do this.
+		 */
+		if (rte->security_barrier)
+			return;
+
+		/*
 		 * OK, fetch RelOptInfo for subquery.  Note that we don't change the
 		 * rel returned in vardata, since caller expects it to be a rel of the
 		 * caller's query level.  Because we might already be recursing, we