]> granicus.if.org Git - postgresql/commit
In locate_grouping_columns(), don't expect an exact match of Var typmods.
authorTom Lane <tgl@sss.pgh.pa.us>
Fri, 23 Aug 2013 21:30:56 +0000 (17:30 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 23 Aug 2013 21:30:56 +0000 (17:30 -0400)
commitc19617d5355e41074623bbb7c3efda532c20f637
tree067ffb3f0cb49b24ff1b4e0fa1710f62e21de55c
parente6d3f5b35edad5452936bf4842167fa00c8b64b8
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.
src/backend/optimizer/plan/planner.c
src/backend/optimizer/util/tlist.c
src/include/optimizer/tlist.h
src/test/regress/expected/rangefuncs.out
src/test/regress/sql/rangefuncs.sql