Re: [HACKERS] Re: Apparent bug in _make_subplan
| От | Tom Lane |
|---|---|
| Тема | Re: [HACKERS] Re: Apparent bug in _make_subplan |
| Дата | |
| Msg-id | 7441.929715584@sss.pgh.pa.us обсуждение |
| Ответ на | Re: [HACKERS] Re: Apparent bug in _make_subplan (Vadim Mikheev <vadim@krs.ru>) |
| Список | pgsql-hackers |
Vadim Mikheev <vadim@krs.ru> writes:
>> But the varlevelsup I pass in from the parser are relative to the
>> current level, not absolute.
> subselect.c takes it into account, computes absolute numbers
> and stores them in PlannerParamVar only...
Right, I eventually figured that out, and I see that it's probably the
best way. I have added the following documentation to subselect.c:
/*--------------------* PlannerParamVar is a list of Var nodes, wherein the n'th entry* (n counts from 0) corresponds
toParam->paramid = n. The Var nodes* are ordinary except for one thing: their varlevelsup field does NOT* have the
usualinterpretation of "subplan levels out from current".* Instead, it contains the absolute plan level, with the
outermost*plan being level 1 and nested plans having higher level numbers.* This nonstandardness is useful because we
don'thave to run around* and update the list elements when we enter or exit a subplan* recursion level. But we must
payattention not to confuse this* meaning with the normal meaning of varlevelsup.*--------------------*/
along with other changes that I will commit once I get subselects in
HAVING working right ...
regards, tom lane
В списке pgsql-hackers по дате отправления: