On Thu, Oct 8, 2009 at 3:30 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@commandprompt.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