diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2016-05-21 12:55:31 -0400 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2016-05-21 12:55:31 -0400 |
| commit | 82eafabeaaf12231a85ed67bbf4eae698aacb1c9 (patch) | |
| tree | c339385837d7becaea12df5180dda4cb55013f19 /src/backend/executor/nodeFunctionscan.c | |
| parent | 50e5315a58554735096f7530cb766fae2dd3b0c7 (diff) | |
| download | postgresql-82eafabeaaf12231a85ed67bbf4eae698aacb1c9.tar.gz postgresql-82eafabeaaf12231a85ed67bbf4eae698aacb1c9.zip | |
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>
Diffstat (limited to 'src/backend/executor/nodeFunctionscan.c')
0 files changed, 0 insertions, 0 deletions