Re: Apparent bug in _make_subplan

From: Vadim Mikheev <vadim(at)krs(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Apparent bug in _make_subplan
Date: 1999-06-17 01:49:50
Message-ID: 3768543E.A41A8AD5@krs.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Inoue 1999-06-17 03:20:31 RE: [HACKERS] Savepoints...
Previous Message Tatsuo Ishii 1999-06-17 00:53:21 Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem