Re: Guidance on INSERT RETURNING order

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Federico <cfederico87(at)gmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, John Howroyd <jdhowroyd(at)googlemail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Guidance on INSERT RETURNING order
Date: 2023-04-15 03:17:09
Message-ID: 1608813.1681528629@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Federico <cfederico87(at)gmail(dot)com> writes:
> 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.

As proposed, I don't think so. Something over in the RETURNING clause has
exactly no connection to VALUES. What do you do if it's INSERT ... SELECT
and there are several VALUES clauses down inside the SELECT?

There is some prior art in this area, though. See the more-or-less
SQL-standard WITH ORDINALITY option for functions-in-FROM. It seems to me
that it could be plausible to attach WITH ORDINALITY to a VALUES clause,
which would give you a rock-solid connection between the VALUES rows and
the ordinality-column values, and then you could include that column in
RETURNING.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2023-04-15 03:39:56 Re: Guidance on INSERT RETURNING order
Previous Message vignesh C 2023-04-15 01:08:59 Re: Support logical replication of DDLs