On Fri, 14 Apr 2023 at 21:37, David G. Johnston
<david.g.johnston@xxxxxxxxx> wrote:
>
> On Fri, Apr 14, 2023 at 11:42 AM John Howroyd <jdhowroyd@xxxxxxxxxxxxxx> wrote:
>>
>> @PostgreSQL: Might I ask if this is still being actively considered or should we repost to another mailing list (perhaps pgsql-hackers or any other you might suggest)?
>
>
> This is the right place for such a discussion. Unless you think you've come up with a design that you want to propose and that, if accepted, you would then write up a patch for. For that you'd probably want to move the discussion to -hackers with an outline of the patch you plan to write.
>
> David J.
>
Would something like what was proposed by Mike Bayer be considered?
> A new token called "tuple_order" or something
>
> INSERT INTO table (a, b, c) VALUES ((1, 2, 3), (4, 5, 6), ...) RETURNING table.id, inserted.tuple_order
>
> tuple_order would be incrementing values 1, 2, 3, 4, 5, ... which correlate the each row delivered by RETURNING to each entry in the VALUES clause, in the order they were stated in that VALUES clause, that is entry (1, 2, 3) would be tuple_order 1, entry (4, 5, 6) would be tuple order 2, etc.
This would allow easy reordering of the RETURNING clause, either
client side or moving the INSERT into a CTE and ordering the outside
select. I also don't think it would have any impact on parallel
processing of the INSERT, since RETURNING could output rows in any
arbitrary order.
Best,
Federico
