Re: RETURNING order guarantees documentation

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Sat, May 4, 2024, 10:13 Dan Wainwright <danw(dot)cobus(at)gmail(dot)com> wrote:
>> 'Similar to' doesn't provide anything concrete to the reader. There was a thread
>> on [Hackers]
>> <https://www.mail-archive.com/pgsql-hackers(at)postgresql(dot)org/msg253743.html>
>> back in 2015 proposing some docs to clearly explain that ordering is
>> preserved and I am keen to write the documentation if it's agreed to be
>> worth doing.

> Haven't reviewed the discussions recently but my understanding is that the
> lack of guarantee is correct and intentional. There is none.

Indeed. If you must have ordering you can do something like

with upd as (update foo set ... returning *)
select * from upd order by ...;

Otherwise it's going to be the order in which the rows were processed
by the ModifyTable node, which is intentionally unspecified.

The thread Dan refers to is here:

https://www.postgresql.org/message-id/flat/CAMsr%2BYEn5TOuhv_tTwY70S1zXf8jCQ-uixU8aOs4OQs7kojf6Q%40mail.gmail.com

and it doesn't seem to have gone anywhere. But I see that Craig
was really only concerned with whether INSERTs are processed in the
order returned by the data source, which is probably a pretty safe
assumption. Still, SQL is a set-oriented language which means that
it generally doesn't guarantee anything about row order, with the
sole exception being the immediate output of a SELECT ... ORDER BY.
So I think adding such guarantees isn't a great idea.

regards, tom lane