Re: Using results from INSERT ... RETURNING

On Tue, Sep 22, 2009 at 11:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> writes:
>> Robert Haas wrote:
>>> Can you explain the motivation for changing the Append stuff as part
>>> of this patch?  It's not immediately clear to me why that needs to be
>>> done as part of this patch or what we get out of it.
>
>> It seemed to me that the Append on top was only a workaround for the
>> fact that we didn't have a node for DML operations that would select the
>> correct result relation.  I don't see why an Append node should do this
>> at all if we have a special node for handling DML.
>
> The stuff for inherited target relations is certainly ugly, and if this
> can clean it up then so much the better ... but is a DML node that has
> to deal with multiple targets really better?  It's not only the Append
> itself that's funny, it's the fact that the generated tuples don't all
> have the same tupdesc in UPDATE cases.
>
>
> FWIW, I'd think of having three separate node types Insert, Update,
> Delete, not a combined Dml node.  The behavior and the required inputs
> are sufficiently different that I don't think a combined node type
> is saving much.  And it'd avoid the "what is that?" problem.

Right now, it looks like most of the code is being shared between all
three plan types. I'm pretty suspicious of how much code this patch
moves around and how little of it is actually changed. I can't really
tell if there's an actual design improvement here or if this is all
window-dressing.

...Robert