]> granicus.if.org Git - postgresql/commit
Don't apply sortgroupref labels to a tlist that might not match.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 28 Jun 2016 14:43:11 +0000 (10:43 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 28 Jun 2016 14:43:11 +0000 (10:43 -0400)
commitc12f02ffc94faac09eae254b3bf114c153f116f6
tree24cc94264d9210751042ef9901ef69d0f85698f7
parent957616dbaef0e7f182e6260483bca79a38ae247f
Don't apply sortgroupref labels to a tlist that might not match.

If we need to use a gating Result node for pseudoconstant quals,
create_scan_plan() intentionally suppresses use_physical_tlist's checks
on whether there are matches for sortgroupref labels, on the grounds that
we don't need matches because we can label the Result's projection output
properly.  However, it then called apply_pathtarget_labeling_to_tlist
anyway.  This oversight was harmless when written, but in commit aeb9ae645
I made that function throw an error if there was no match.  Thus, the
combination of a table scan, pseudoconstant quals, and a non-simple-Var
sortgroupref column threw the dreaded "ORDER/GROUP BY expression not found
in targetlist" error.  To fix, just skip applying the labeling in this
case.  Per report from Rushabh Lathia.

Report: <CAGPqQf2iLB8t6t-XrL-zR233DFTXxEsfVZ4WSqaYfLupEoDxXA@mail.gmail.com>
src/backend/optimizer/plan/createplan.c
src/test/regress/expected/aggregates.out
src/test/regress/sql/aggregates.sql