Re: [HACKERS] Re: Apparent bug in _make_subplan

Vadim Mikheev <vadim(at)krs(dot)ru> writes:
>> 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

No, it's never 0. It starts out 1 in planner(), and _make_subplan
increments it at line 116 before recursing, then decrements again at
line 142. So it's at least one when we arrive at the parParam code.

> 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.

After looking through all the references to varlevelsup, it's clear
that all pieces of the system *except* subselect.c treat varlevelsup
as a relative level number, so-many-levels-out-from-current-subplan.
subselect.c has a couple of places that think nonzero varlevelsup
is an absolute level number, with 1 as the top plan. This is certainly
a source of bugs --- it happens to work for two-level plans, but will
fail for anything more deeply nested. I will work on fixing subselect.c
to bring it in line with the rest of the world...

regards, tom lane