Re: Guidance on INSERT RETURNING order

On Fri, Apr 14, 2023 at 8:17 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> 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.
>
>
I suppose breaking the restriction that only columns present on the
insertion-table can be returned is a possible option that also solves
another infrequent request.

Adding with ordinality to the values clause seems like an independent
feature that has merit on its own for the same reason SRFs have that option.

Ultimately, though, whatever is supplying the rows to the insert is going
to have to supply them in some order, and the returning clause can simply
modify the executor to perform an initial pass over the input data in order
to assign the ordering indexes before allowing for parallelism, and then
sort again on the way out. User-space does/should not need to create data
for this purpose. A top-level values query should not need to be specified
with ordinality while subquery ones would be hidden from the mechanism, the
parent query being responsible for any ordering that is desired.

David J.