Re: Guidance on INSERT RETURNING order

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Federico <cfederico87(at)gmail(dot)com>
Cc: 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-14 22:22:42
Message-ID: CAKFQuwa9ZKVTFSBm80=dZBsHAQdqr_dgoxnthrmPHswAMPggZg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Apr 14, 2023 at 12:47 PM Federico <cfederico87(at)gmail(dot)com> wrote:

>
> 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.
>
>
Personally, yes, a declarative syntax specifying the desired behavior and
thus giving the system permission to potentially trade optimizations for a
deterministic output is the way forward. Ideally current and future
optimizations/performance characteristics could be maintained even in the
presence of this option but ultimately the system would be compelled to
return records in the specified order no matter the cost. For bonus
points, the impact on queries that do not specify this option should be as
close to nothing as possible - though I/O is likely to make some increase
negligible.

David J.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Karsten Hilbert 2023-04-14 22:44:16 Re: Guidance on INSERT RETURNING order
Previous Message David G. Johnston 2023-04-14 22:14:12 Re: Guidance on INSERT RETURNING order