pgsql-v9.2-fix-leaky-view-part-1.v8.option-2.patch

 src/backend/utils/adt/selfuncs.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/src/backend/utils/adt/selfuncs.c b/src/backend/utils/adt/selfuncs.c
index f5660b2..4fec5be 100644
--- a/src/backend/utils/adt/selfuncs.c
+++ b/src/backend/utils/adt/selfuncs.c
@@ -4344,6 +4344,14 @@ examine_simple_variable(PlannerInfo *root, Var *var,
 	else if (rte->rtekind == RTE_RELATION)
 	{
 		/*
+		 * XXX - Extension module may append qualifiers to apply its row-level
+		 * security policy on the table. We disallow to reference pg_statistic
+		 * in same reason with security-barrier views.
+		 */
+		if (rte->security_barrier)
+			return;
+
+		/*
 		 * Plain table or parent of an inheritance appendrel, so look up the
 		 * column in pg_statistic
 		 */
@@ -4373,6 +4381,16 @@ examine_simple_variable(PlannerInfo *root, Var *var,
 			return;
 
 		/*
+		 * If sub-query would originate from a view with security_barrier
+		 * property, it should perform as a black-box from outside of the
+		 * view. If and when an operator function has side-effects that
+		 * allows to leak its arguments, it can be used to break row-level
+		 * security configuration using a view.
+		 */
+		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