Re: [HACKERS] Re: Apparent bug in _make_subplan - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Re: Apparent bug in _make_subplan
Date
Msg-id 3927.929630624@sss.pgh.pa.us
Whole thread Raw
In response to Re: Apparent bug in _make_subplan  (Vadim Mikheev <vadim@krs.ru>)
Responses Re: [HACKERS] Re: Apparent bug in _make_subplan
List pgsql-hackers
Vadim Mikheev <vadim@krs.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


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: CLI interface
Next
From: Thomas Lockhart
Date:
Subject: Cleaned up CVS repository!