1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-14 08:21:07 +03:00

Correctly update hasSubLinks while mutating a rule action.

rewriteRuleAction neglected to check for SubLink nodes in the
securityQuals of range table entries.  This could lead to failing
to convert such a SubLink to a SubPlan, resulting in assertion
crashes or weird errors later in planning.

In passing, fix some poor coding in rewriteTargetView:
we should not pass the source parsetree's hasSubLinks
field to ReplaceVarsFromTargetList's outer_hasSubLinks.
ReplaceVarsFromTargetList knows enough to ignore that
when a Query node is passed, but it's still confusing
and bad precedent: if we did try to update that flag
we'd be updating a stale copy of the parsetree.

Per bug #17972 from Alexander Lakhin.  This has been broken since
we added RangeTblEntry.securityQuals (although the presented test
case only fails back to 215b43cdc), so back-patch all the way.

Discussion: https://postgr.es/m/17972-f422c094237847d0@postgresql.org
This commit is contained in:
Tom Lane
2023-06-13 15:58:37 -04:00
parent edf1de65e5
commit b4110bdbfe
3 changed files with 52 additions and 1 deletions

View File

@ -472,6 +472,8 @@ rewriteRuleAction(Query *parsetree,
/* other RTE types don't contain bare expressions */
break;
}
sub_action->hasSubLinks |=
checkExprHasSubLink((Node *) rte->securityQuals);
if (sub_action->hasSubLinks)
break; /* no need to keep scanning rtable */
}
@ -3304,7 +3306,7 @@ rewriteTargetView(Query *parsetree, Relation view)
view_targetlist,
REPLACEVARS_REPORT_ERROR,
0,
&parsetree->hasSubLinks);
NULL);
/*
* Update all other RTI references in the query that point to the view