aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2016-06-28 10:43:11 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2016-06-28 10:43:11 -0400
commitc12f02ffc94faac09eae254b3bf114c153f116f6 (patch)
tree24cc94264d9210751042ef9901ef69d0f85698f7 /src/backend/access/gist
parent957616dbaef0e7f182e6260483bca79a38ae247f (diff)
downloadpostgresql-c12f02ffc94faac09eae254b3bf114c153f116f6.tar.gz
postgresql-c12f02ffc94faac09eae254b3bf114c153f116f6.zip
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>
Diffstat (limited to 'src/backend/access/gist')
0 files changed, 0 insertions, 0 deletions