Don't split up SRFs when choosing to postpone SELECT output expressions.
In commit 9118d03a8cca3d97 we taught the planner to postpone evaluation of
set-returning functions in a SELECT's targetlist until after any sort done
to satisfy ORDER BY. However, if we postpone some SRFs this way while
others do not get postponed (because they're sort or group key columns)
we will break the traditional behavior by which all SRFs in the tlist run
in-step during ExecTargetList(), so that you get the least common multiple
of their periods not the product. Fix make_sort_input_target() so it will
not split up SRF evaluation in such cases.
There is still a hazard of similar odd behavior if there's a SRF in a
grouping column and another one that isn't, but that was true before
and we're just trying to preserve bug-compatibility with the traditional
behavior. This whole area is overdue to be rethought and reimplemented,
but we'll try to avoid changing behavior until then.
Per report from Regina Obe.
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/d543170f2fdd6d9845aaf91dc0f6be7a2bf0d9e7
Modified Files
--------------
src/backend/optimizer/plan/planner.c | 48 ++++++++++++++++++++++++++----------
src/test/regress/expected/limit.out | 38 ++++++++++++++++++++++++++++
src/test/regress/sql/limit.sql | 13 ++++++++++
3 files changed, 86 insertions(+), 13 deletions(-)
