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

tglsfdc · tglsfdc · commit 82eafabeaaf1 · 2016-05-21T12:55:31.000-04:00
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: &lt;CAKFQuwbAX=iO9QbpN7_jr+BnUWm9FYX8WbEPUvG0p+nZhp6TZg@mail.gmail.com&gt;
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
@@ -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>
