From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, PostgreSQL hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Using results from INSERT ... RETURNING |
Date: | 2009-10-08 20:13:59 |
Message-ID: | 603c8f070910081313g3237019k253f1679adfabaf6@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 8, 2009 at 3:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> Robert Haas escribió:
>>> On Thu, Oct 8, 2009 at 3:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> 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.
>
>> Perhaps how a join is implemented in a plan can be considered a
>> "detail", but I don't think the same holds true for insert vs. update.
>
> Also, in all the other cases we stuck the detail into a common
> attribute called Strategy. What bothers me about Operation is that
> there is only one node type that it is good for. I would prefer to
> keep the text and XML representations of this the same, which at the
> moment seems to mean that the node type should be reported as
> Insert/Update/Delete.
Hmm... well, when you initially committed the code, you complained
that there were two different and unrelated things both using the
strategy tag - really, to mean different things. Now you're saying
that strategy is OK because it's grand-fathered, but we shouldn't add
any more.
I think there's value in keeping the types that we output in 1-1
correspondence with the internal node tags. We have other
node-specific properties that aren't handled that way like "Scan
Direction". The only thing that's different about strategy is that it
happens to be handled in the first "case" block rather than the second
one for reasons that are entirely cosmetic rather than substantive.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-10-08 20:16:38 | Re: Using results from INSERT ... RETURNING |
Previous Message | Greg Smith | 2009-10-08 20:11:06 | Re: [PATCH] pgbench: new feature allowing to launch shell commands |