Re: [PATCH] Enforce that INSERT...RETURNING preserves the order of multi rows - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: [PATCH] Enforce that INSERT...RETURNING preserves the order of multi rows
Date
Msg-id 50842FE4.8080509@dunslane.net
Whole thread Raw
In response to Re: [PATCH] Enforce that INSERT...RETURNING preserves the order of multi rows  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Re: [PATCH] Enforce that INSERT...RETURNING preserves the order of multi rows  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [PATCH] Enforce that INSERT...RETURNING preserves the order of multi rows  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 10/21/2012 12:36 PM, Andres Freund wrote:
> On Sunday, October 21, 2012 06:30:14 PM Andrew Dunstan wrote:
>> On 10/21/2012 12:20 PM, Abhijit Menon-Sen wrote:
>>> At 2012-10-21 11:49:26 -0400, cbbrowne@gmail.com wrote:
>>>> If there is a natural sequence (e.g. - a value assigned by nextval()),
>>>> that offers a natural place to apply the usual order-imposing ORDER BY
>>>> that we are expected to use elsewhere.
>>> Note: "INSERT … RETURNING" doesn't accept an ORDER BY clause.
>> No, but you can wrap the INSERT .. RETURNING in a CTE and order that.
> Personally I find that a not very practical suggestion. It means you need the
> ability to sort the data equivalently on the clientside which isn't always
> easy if you consider platform/locale and whatever differences.


Er, what?
   with orig_inserts as   (        insert into table_1        ...        returning *   ),   ordered_inserts as   (
 select * from orig_inserts        order by ...   )   insert into table_2   select * from ordered_inserts ...; 

why does the client have to be involved, exactly?

cheers

andrew




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Successor of MD5 authentication, let's use SCRAM
Next
From: Tom Lane
Date:
Subject: Re: Re: [PATCH] Enforce that INSERT...RETURNING preserves the order of multi rows