On 7/19/2009, "Tom Lane" <t...@sss.pgh.pa.us> wrote: > The way that I think this should be approached is > (1) a code-refactoring patch that moves INSERT/UPDATE/DELETE control > into plan nodes; then > (2) a feature patch that makes use of that to expose RETURNING in CTEs.
I've been working on this and here's a patch I came up with. It's a WIP that tries to put together my thoughts about this. It works only for INSERT and DELETE and probably breaks with triggers. In the attached patch, an Append node isn't added for inheritance sets. Instead, the UPDATE/DELETE node tries to take care of choosing the correct result relation. I tried to keep estate->es_result_relations as it is in order not to break anything that relies on it (for example ExecRelationIsTargetRelation) but estate->es_result_relation_info doesn't point to the target relation of the DML node any more. This was replaced with a pointer in DmlState to make it possible to add more DML nodes in the future. Also the result relation info initialization was moved to the node, because InitResultRelInfo needs to know the type of operation that is going to be performed on the result relation. Currently that info isn't available at the top level, so I went this way. I'm not happy with it, but couldn't come up with better ideas. Currently the result relation for SELECT FOR UPDATE/SHARE isn't initialized anywhere, so that won't work. The patch doesn't do this, but the idea was that if the DML node has a RETURNING clause, the node returns the projected tuple and ExecutePlan sends it to the DestReceiver. In cases where there is no RETURNING clause, the node would return a dummy tuple. Comments are welcome. Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
