| From: | Vik Reykja <vikreykja(at)gmail(dot)com> |
|---|---|
| To: | "P(dot) Christeas" <xrg(at)linux(dot)gr> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Re: [PATCH] Enforce that INSERT...RETURNING preserves the order of multi rows |
| Date: | 2012-10-22 03:23:35 |
| Message-ID: | CALDgxVurnMTTyzvhrRTx4YDkDoGS=fcXTNjX-7Oq22EfXfTz+A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Oct 21, 2012 at 11:35 PM, P. Christeas <xrg(at)linux(dot)gr> wrote:
> On Sunday 21 October 2012, Vik Reykja wrote:
> > On Sun, Oct 21, 2012 at 6:20 PM, Abhijit Menon-Sen
> <ams(at)2ndquadrant(dot)com>wrote:
> > > Note: "INSERT … RETURNING" doesn't accept an ORDER BY clause.
> >
> > Would anyone be opposed to somebody - say, me - writing a patch to allow
> > that? It would take me a lot longer than an experienced hacker to do it,
> > but I'm willing to try.
>
>
> I would oppose, for one.
>
> Please, don't waste your time. Reordering the INSERT .. RETURNING results
> is
> already possible today, with some nested syntax. At the same time, bloating
> the INSERT syntax with SELECT semantics would be negative IMO. And I would
> see
> little use in having such a feature.
>
I wasn't thinking of bloating InsertStmt but returning_clause. There's no
reason UpdateStmt and DeleteStmt shouldn't benefit also.
But I'll hold off for now.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rushabh Lathia | 2012-10-22 05:24:03 | Re: assertion failure w/extended query protocol |
| Previous Message | Kevin Grittner | 2012-10-21 22:34:38 | Re: Bugs in CREATE/DROP INDEX CONCURRENTLY |