From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, 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-07-19 18:28:34 |
Message-ID: | 603c8f070907191128i34bfbc3et88e194dc1e1a65d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jul 19, 2009 at 12:39 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I think this is a great feature, and it would be REALLY great if it
>> supported UPDATE and DELETE as well.
>
> It won't get applied until it does, and I imagine the patch author
> wasn't expecting any differently. The submission was clearly marked
> "WIP" not "ready to apply".
>
>> However, it sounds to me like this is going to need more reworking
>> than is going to get done in the next week or two.
>
> Yeah. I did a quick scan of the patch and was distressed at how much of
> it seemed to be addition of new code; that implies that he's more or
> less duplicated the top-level executor processing.
>
> The way that I think this should be approached is
> (1) a code-refactoring patch that moves INSERT/UPDATE/DELETE control
> into plan nodes; then
> (2) a feature patch that makes use of that to expose RETURNING in CTEs.
>
> One thing that's not totally clear to me is whether we'd like to use
> control plan nodes all the time, or only for statements with RETURNING.
> The nice thing about the latter approach is that there's a well-defined
> meaning for the plan node's targetlist. (Its input is the stuff to be
> stored, its output is the RETURNING result; much cleaner than the way
> RETURNING is bolted onto the executor now.) If we do it all the time
> then the control nodes would have dummy targetlists for non-RETURNING
> cases, which is a little bit ugly. OTOH it may not be practical to
> handle it like that without a lot of code duplication.
>
> Another thing to think about is whether there should be three types
> of control nodes or only one.
>
> But anyway, my $0.02 is that the *first* order of business is to propose
> a suitable refactoring of execMain.c. We skipped doing that when we
> first added RETURNING, but it's time to make it happen. Not fasten
> another kluge on top of a kluge.
Tom,
This is a great review and great input. I wish there were enough
hours in the day for you to do something like this for every patch. I
feel good about saying that this is Returned With Feedback at this
point, and I see that Jaime Casanova has already made that update.
Thanks very much,
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-07-19 18:35:05 | Re: GEQO vs join order restrictions |
Previous Message | Robert Haas | 2009-07-19 18:25:09 | Re: Sampling profiler updated |