In locate_grouping_columns(), don't expect an exact match of Var typmods.
It's possible that inlining of SQL functions (or perhaps other changes?)
has exposed typmod information not known at parse time. In such cases,
Vars generated by query_planner might have valid typmod values while the
original grouping columns only have typmod -1. This isn't a semantic
problem since the behavior of grouping only depends on type not typmod,
but it breaks locate_grouping_columns' use of tlist_member to locate the
matching entry in query_planner's result tlist.
We can fix this without an excessive amount of new code or complexity by
relying on the fact that locate_grouping_columns only gets called when
make_subplanTargetList has set need_tlist_eval == false, and that can only
happen if all the grouping columns are simple Vars. Therefore we only need
to search the sub_tlist for a matching Var, and we can reasonably define a
"match" as being a match of the Var identity fields
varno/varattno/varlevelsup. The code still Asserts that vartype matches,
but ignores vartypmod.
Per bug #8393 from Evan Martin. The added regression test case is
basically the same as his example. This has been broken for a very long
time, so back-patch to all supported branches.
Branch
------
REL8_4_STABLE
Details
-------
http://git.postgresql.org/pg/commitdiff/70ebdd084484d5dbea04a04d425334600818f2fe
Modified Files
--------------
src/backend/optimizer/plan/planner.c | 21 ++++++++++++++++++---
src/backend/optimizer/util/tlist.c | 29 +++++++++++++++++++++++++++++
src/include/optimizer/tlist.h | 1 +
src/test/regress/expected/rangefuncs.out | 11 +++++++++++
src/test/regress/sql/rangefuncs.sql | 7 +++++++
5 files changed, 66 insertions(+), 3 deletions(-)