Re: Guidance on INSERT RETURNING order
От | Federico |
---|---|
Тема | Re: Guidance on INSERT RETURNING order |
Дата | |
Msg-id | CAN19dye=rfDRL=40QDko=yPggE0rotesr2sg1LSih-1c7v0fZQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Guidance on INSERT RETURNING order ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: Guidance on INSERT RETURNING order
Re: Guidance on INSERT RETURNING order |
Список | pgsql-general |
On Fri, 14 Apr 2023 at 21:37, David G. Johnston <david.g.johnston@gmail.com> wrote: > > On Fri, Apr 14, 2023 at 11:42 AM John Howroyd <jdhowroyd@googlemail.com> wrote: >> >> @PostgreSQL: Might I ask if this is still being actively considered or should we repost to another mailing list (perhapspgsql-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 proposeand 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 eachentry in the VALUES clause, in the order they were stated in that VALUES clause, that is entry (1, 2, 3) would be tuple_order1, 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
В списке pgsql-general по дате отправления: