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

Another round of planner fixes for LATERAL.

Browse Source 
Formerly, subquery pullup had no need to examine other entries in the range
table, since they could not contain any references to the subquery being
pulled up.  That's no longer true with LATERAL, so now we need to be able
to visit rangetable subexpressions to replace Vars referencing the
pulled-up subquery.  Also, this means that extract_lateral_references must
be unsurprised at encountering lateral PlaceHolderVars, since such might be
created when pulling up a subquery that's underneath an outer join with
respect to the lateral reference.
This commit is contained in:
Tom Lane
2012-08-18 14:10:17 -04:00
parent 18226849ea
commit 084a29c94f
5 changed files with 205 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
src/backend/optimizer/plan/initsplan.c
View File

@ -237,14 +237,30 @@ extract_lateral_references(PlannerInfo *root, int rtindex)
else
return;
/* Copy each Var and adjust it to match our level */
/* Copy each Var (or PlaceHolderVar) and adjust it to match our level */
newvars = NIL;
foreach(lc, vars)
{
Var *var = (Var *) lfirst(lc);
Node *var = (Node *) lfirst(lc);
var = copyObject(var);
var->varlevelsup = 0;
if (IsA(var, Var))
{
((Var *) var)->varlevelsup = 0;
}
else if (IsA(var, PlaceHolderVar))
{
/*
* It's sufficient to set phlevelsup = 0, because we call
* add_vars_to_targetlist with create_new_ph = false (as we must,
* because deconstruct_jointree has already started); therefore
* nobody is going to look at the contained expression to notice
* whether its Vars have the right level.
*/
((PlaceHolderVar *) var)->phlevelsup = 0;
}
else
Assert(false);
newvars = lappend(newvars, var);
}