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