Re: UPDATE using sub selects - Mailing list pgsql-hackers

From NikhilS
Subject Re: UPDATE using sub selects
Date
Msg-id d3c4af540704110204o3d67bad8l6a837d1dda111f1f@mail.gmail.com
Whole thread Raw
In response to Re: UPDATE using sub selects  (NikhilS <nikkhils@gmail.com>)
List pgsql-hackers
Hi,
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

pgsql-hackers by date:

Previous
From: "Pavan Deolasee"
Date:
Subject: Re: CIC and deadlocks
Next
From: "Zeugswetter Andreas ADI SD"
Date:
Subject: conflicting gettimeofday with MinGW