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:
parent
50e5315a58
commit
82eafabeaa
|
@ -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>
|
||||
|
|
Loading…
Reference in New Issue