Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Ah, thanks for the simplified test case. This is undoubtedly my fault
>> ... will look into it. It is probably somewhat related to the join
>> alias problem found yesterday (ie, somebody somewhere is trying to use
>> the wrong rangetable list to interpret a Var node).
> I spent a bit more time on it last night. Here's an even simpler example:
The answer is that it was brain fade on my part when I wrote the code
for showing plan qualification expressions in EXPLAIN. SubqueryScan
should be classed as a scan node, not an upper node --- it *is* a
primitive scan, from the point of view of the upper query. So any Vars
in its qual have to be resolved against the upper rangetable, not the
subplan's rangetable.
The diff against 7.3 is attached.
regards, tom lane
*** src/backend/commands/explain.c.orig Mon Oct 14 00:26:54 2002
--- src/backend/commands/explain.c Fri Dec 6 14:16:48 2002
***************
*** 432,437 ****
--- 432,438 ----
break;
case T_SeqScan:
case T_TidScan:
+ case T_SubqueryScan:
case T_FunctionScan:
show_scan_qual(plan->qual, false,
"Filter",
***************
*** 483,495 ****
"Filter",
"outer", OUTER,
outerPlan(plan),
"inner", INNER,
innerPlan(plan),
- str, indent, es);
- break;
- case T_SubqueryScan:
- show_upper_qual(plan->qual,
- "Filter",
- "subplan", 1, ((SubqueryScan *)
plan)->subplan,
- "", 0, NULL,
str, indent, es);
break;
case T_Agg:
--- 484,489 ----
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
