rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix Var handling for security barrier views 

In some cases, not all Vars were being correctly marked as having been
modified for updatable security barrier views, which resulted in invalid
plans (eg: when security barrier views were created over top of
inheiritance structures).

In passing, be sure to update both varattno and varonattno, as _equalVar
won't consider the Vars identical otherwise.  This isn't known to cause
any issues with updatable security barrier views, but was noticed as
missing while working on RLS and makes sense to get fixed.

Back-patch to 9.4 where updatable security barrier views were
introduced.
This commit is contained in:
Stephen Frost 2014-08-26 23:08:41 -04:00
parent 8e484bc4ab
commit e414ba93ad
1 changed files with 4 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
src/backend/optimizer/prep/prepsecurity.c
View File

@ -398,7 +398,9 @@ security_barrier_replace_vars_walker(Node *node,
((Var *) tle->expr)->varcollid == var->varcollid)
{
/* Map the variable onto this subquery targetlist entry */
var->varattno = attno;
var->varattno = var->varoattno = attno;
/* Mark this var as having been processed */
context->vars_processed = lappend(context->vars_processed, var);
return false;
}
}
@ -444,7 +446,7 @@ security_barrier_replace_vars_walker(Node *node,
makeString(pstrdup(attname)));
/* Update the outer query's variable */
var->varattno = attno;
var->varattno = var->varoattno = attno;
/* Remember this Var so that we don't process it again */
context->vars_processed = lappend(context->vars_processed, var);