Re: [HACKERS] Re: Apparent bug in _make_subplan
От | Vadim Mikheev |
---|---|
Тема | Re: [HACKERS] Re: Apparent bug in _make_subplan |
Дата | |
Msg-id | 3769C6D1.5E65A5B0@krs.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: Apparent bug in _make_subplan (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Re: Apparent bug in _make_subplan
|
Список | pgsql-hackers |
Tom Lane wrote: > > > 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... subselect.c uses varlevelsup as absolute level number only for correlation vars <--> params mapping, so why should it be source of bugs? SS_replace_correlation_vars replaces all correlation vars with parameters. Vars with absolute varlevelsup are in PlannerParamVar only. To identify correlation vars and to know is parameter already assigned to a var we obviously need in absolute level number. Vadim
В списке pgsql-hackers по дате отправления: