Re: Apparent bug in _make_subplan

Поиск
Список
Период
Сортировка
От Vadim Mikheev
Тема Re: Apparent bug in _make_subplan
Дата
Msg-id 3768543E.A41A8AD5@krs.ru
обсуждение исходный текст
Ответ на Apparent bug in _make_subplan  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Re: Apparent bug in _make_subplan
Список 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 по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem
Следующее
От: "Hiroshi Inoue"
Дата:
Сообщение: RE: [HACKERS] Savepoints...