Tom Lane wrote:
>
> More generally, however, I think that the very existence of the subPlan
> list is a bug. It violates the notion that "pointer equality shouldn't
> matter" because the subPlan list *must* contain pointers to the actual
> member objects of a plan node's other substructure.
>
> Moreover the subPlan list isn't even buying us much --- it wouldn't be
> that expensive to scan the substructure directly for plan-type nodes
> when necessary, exactly as SS_pull_subplan does. Arguably this would
> take less time than is expended on memory allocation to build the
> explicit subPlan list. So I suggest getting rid of the subPlan list
> entirely, rather than hacking on copyfuncs.
First, I apologize for any inconveniences in my implementation
of subselect. I agreed that current handling of subPlan lists
is bad, but parent plan need in this list for some initializations
and SUBPLAN_EXPR expressions inside parent plan also need in
corresponding subPlan nodes (to execute them).
Well, this could be good solution:
1. Implement TopPlan node (upmost plan, we told about this and seems that Jan wanted implement it).
2. Construct list of _all_ subPlan inside planner and put this list into TopPlan node.
3. Put into Plan->subPlan list of _indices_ of subPlans used in this Plan (indices in TopPlan->subPlan list).
4. Use indices in SUBPLAN_EXPR, istead of subPlan pointers.
5. Add to EState and ExprContext pointer to TopPlan->subPlan list (to enable index --> node conversion in
ExecSubPlan()& ExecInitSubPlan()).
Unfortunately, I missed this solution year ago -:(
And more of that, I have no time to implement this now, sorry.
> Plans also have an "initPlan" list that seems to have the same kind of
> problem. I don't really understand the difference between initPlans
No problems here. As you see this list is just copied in copyfuncs
and this is ok.
> and subPlans --- plannodes.h says
> List *initPlan; /* Init Plan nodes (un-correlated expr
> * subselects) */
> List *subPlan; /* Other SubPlan nodes */
> which doesn't convey a whole lot to my mind. Does anyone understand
> why this distinction is made? Is it really necessary?
Uncorrelated expression subqueries are processed differently
from all other subqueries.
Vadim
