On 7/19/2009, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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
probably breaks with triggers.
In the attached patch, an Append node isn't added for inheritance sets.
the UPDATE/DELETE node tries to take care of choosing the correct result
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
doesn't point to the target relation of the DML node any more. This was
a pointer in DmlState to make it possible to add more DML nodes in the
the result relation info initialization was moved to the node, because
needs to know the type of operation that is going to be performed on the
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
clause, the node returns the projected tuple and ExecutePlan sends it to
In cases where there is no RETURNING clause, the node would return a
Comments are welcome.
In response to
pgsql-hackers by date
|Next:||From: Marko Tiikkaja||Date: 2009-07-31 16:26:53|
|Subject: Re: Using results from INSERT ... RETURNING|
|Previous:||From: Tom Lane||Date: 2009-07-31 15:25:01|
|Subject: Occasional failures on buildfarm member eukaryote|