Re: Using results from INSERT ... RETURNING

On Thu, Oct 8, 2009 at 3:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Tom Lane escribió:
>> Does it affect how is it going to look in EXPLAIN output?
>
> Hmm, I suppose there's not any law that says EXPLAIN has to print the
> same name we use internally.  The explain output could say "Insert",
> "Update", or "Delete" independently of what we call the node type.

It already does, in text mode.

> That would take away about 50% of my objection to the node name,
> though on balance I still think "Dml" is a poor choice since plan
> node names are typically verbs.

Agreed.

> One issue is whether it would be confusing for implementors if the
> explain output is completely unrelated to the internal name.  We could
> do something like "InsertTable" or "ModifyTable Insert", but both of
> these look a bit ugly from a user's standpoint I think.
>
> I notice also that the patch has chosen to represent Dml in XML/JSON
> explain output as Node Type = Dml with an entirely new attribute
> Operation to indicate Insert/Update/Delete.  Do we really want to
> go there?  Adding single-purpose attributes doesn't seem like a great
> idea.

Well, I was the one who suggested doing it that way, so you can blame
me for that, but it is consistent with how we've handled other things,
like setops and jointypes: the details get moved to another tag so as
to avoid an explosive growth in the number of node types that clients
must be prepared for.

> While we're discussing explain output ... what about triggers?
> An important aspect of this change is that at least the row-level
> triggers are now going to be charged as runtime of the
> Dml-or-whatever-we-call-it node.  Should we rearrange the explain
> output so that the printout for trigger runtimes is associated
> with those nodes too?  If so, what about statement-level triggers?

That's not a bad idea, though it wouldn't bother me much if we left it
for a follow-on patch.

...Robert