Improve docs about using ORDER BY to control aggregate input order.

David Johnston pointed out that the original text here had been obsoleted
by SQL:2008, which allowed ORDER BY in subqueries.  We could weaken the
text to describe ORDER-BY-in-subqueries as an optional SQL feature that's
possibly unportable; but then the exact same statements would apply to
the alternative it's being compared to (ORDER-BY-in-aggregate-calls).
So really that would be pretty useless; let's just take out the sentence
entirely.  Instead, point out the hazard that any extra processing in the
upper query might cause the subquery output order to be destroyed.

Discussion: <CAKFQuwbAX=iO9QbpN7_jr+BnUWm9FYX8WbEPUvG0p+nZhp6TZg@mail.gmail.com>
This commit is contained in:
Tom Lane 2016-05-21 12:55:31 -04:00
parent 50e5315a58
commit 82eafabeaa
1 changed files with 3 additions and 2 deletions

View File

@ -13102,8 +13102,9 @@ SELECT count(*) FROM sometable;
SELECT xmlagg(x) FROM (SELECT x FROM test ORDER BY y DESC) AS tab;
]]></screen>
But this syntax is not allowed in the SQL standard, and is
not portable to other database systems.
Beware that this approach can fail if the outer query level contains
additional processing, such as a join, because that might cause the
subquery's output to be reordered before the aggregate is computed.
</para>
<para>