Hmm. That sounds like it would be a horrid mess. You need to decouple > the execution of the subplan from the use of its outputs, apparently. > There is some precedent for this in the way that InitPlans are handled: > the result of the subplan is stored into a ParamList array entry that's > later referenced by a Param node in the parent's expression tree. That > would generalize easily enough to setting more than one Param, but I'm > not clear on where you'd want to stick the subplan itself in the plan > tree, nor on what controls how often it needs to get evaluated.
Ended up using something similar to the above suggestion. I have posted the patch to -patches based on this. An important concern was where to stick the evaluation of the subqueries so that they end up becoming subplans which are used in the execution. For this I have added a new field in the "Query" structure. This entry gets preprocessed similar to other fields of the Query from within subquery_planner. Regards, Nikhils -- EnterpriseDB http://www.enterprisedb.com