On Fri, 14 Apr 2023 at 21:37, David G. Johnston
<[email protected]> wrote:
>
> On Fri, Apr 14, 2023 at 11:42 AM John Howroyd <[email protected]>
> 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
