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: 

diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 3f627dc885f456816153e4077f2af0585914147e..ff7545de156d2d8fbb8a856769352c6d8c1f6555 100644 (file)
--- 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;
 ]]>
 
-   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.