Re: Insert Documentation - Returning Clause and Order

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: James Coleman <jtc331(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Insert Documentation - Returning Clause and Order
Date: 2021-08-11 16:08:55
Message-ID: CAKFQuwY_Tc7SLiETnJAcCuzGFkH8+crV=a6sPPxxr+CDKLwFRg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 14, 2020 at 7:09 AM Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
wrote:

> But we write what's guaranteed. Anything not written in
> the documents is not guaranteed.
>

In the case of LIMIT we go to great lengths to write what isn't
guaranteed. I suggest that this is similar enough in nature to warrant the
same emphasis.

"Thus, using different LIMIT/OFFSET values to select different subsets of a
query result will give inconsistent results unless you enforce a
predictable result ordering with ORDER BY. This is not a bug; it is an
inherent consequence of the fact that SQL does not promise to deliver the
results of a query in any particular order unless ORDER BY is used to
constrain the order.

It is even possible for repeated executions of the same LIMIT query to
return different subsets of the rows of a table, if there is not an ORDER
BY to enforce selection of a deterministic subset. Again, this is not a
bug; determinism of the results is simply not guaranteed in such a case."

I'd go so far as to say that it's more important here since the observed
behavior is that things are ordered, and expected to be ordered, while with
limit the non-determinism seems more obvious.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jonathan S. Katz 2021-08-11 16:32:41 2021-08-12 release announcement draft
Previous Message Tom Lane 2021-08-11 16:04:10 Re: Next Steps with Hash Indexes