"David G. Johnston" <david.g.johns...@gmail.com> writes: > On Sat, May 4, 2024, 10:13 Dan Wainwright <danw.co...@gmail.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@postgresql.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
