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  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Thomas Lockhart
Дата:
Сообщение: CLI interface
Следующее
От: Thomas Lockhart
Дата:
Сообщение: Cleaned up CVS repository!