Re: Apparent bug in _make_subplan - Mailing list pgsql-hackers

From Vadim Mikheev
Subject Re: Apparent bug in _make_subplan
Date
Msg-id 3768543E.A41A8AD5@krs.ru
Whole thread Raw
In response to Apparent bug in _make_subplan  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Re: Apparent bug in _make_subplan
List pgsql-hackers
Tom Lane wrote:
> 
>     /* make parParam list */
>     foreach(lst, plan->extParam)
>     {
>         Var      *var = nth(lfirsti(lst), PlannerParamVar);
> 
>         if (var->varlevelsup == PlannerQueryLevel)
>             node->parParam = lappendi(node->parParam, lfirsti(lst));
>     }
> 
> It looks to me like this code is supposed to find parameters that
> reference the immediate parent plan level, as opposed to higher levels.
> So, shouldn't it be looking for varlevelsup == 1, not PlannerQueryLevel?
> 
> For a first-level subplan, PlannerQueryLevel will be 1 at the time
> this code runs, so the result is the same anyway.  But I think it

PlannerQueryLevel will be 0 here - subselect.c:140
   /* and now we are parent again */   PlannerInitPlan = saved_ip;   PlannerQueryLevel--;

> does the wrong thing for more deeply nested subplans.  Am I right?

I'm not sure. Seems that I made assumption here that 
varlevelsup is _absolute_ level number and seems that
_replace_var() and _new_param() replace parser' varlevelsup
with absolute level value.

Vadim


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem
Next
From: "Hiroshi Inoue"
Date:
Subject: RE: [HACKERS] Savepoints...