Re: Using results from INSERT ... RETURNING

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.

regards, tom lane