Re: Using results from INSERT ... RETURNING

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Using results from INSERT ... RETURNING
Дата
Msg-id 6827.1255030250@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Using results from INSERT ... RETURNING  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: Using results from INSERT ... RETURNING
Список pgsql-hackers
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.
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.

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.

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?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Concurrency testing
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Writeable CTEs and side effects