diff options
Diffstat (limited to 'src/backend/optimizer/path/allpaths.c')
| -rw-r--r-- | src/backend/optimizer/path/allpaths.c | 14 |
1 files changed, 14 insertions, 0 deletions
diff --git a/src/backend/optimizer/path/allpaths.c b/src/backend/optimizer/path/allpaths.c index 815b996a131..b3777eae2e4 100644 --- a/src/backend/optimizer/path/allpaths.c +++ b/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 */ |