]> 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:31:00 +0000 (17:31 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 23 Aug 2013 21:31:00 +0000 (17:31 -0400)
commitbd5ab4b28745605493ab7061724ba0375ee9593a
tree3bc5f9742b3b44f6019c4b6bc861f1d7dd2bc9a4
parentb94c6c691e86a1d9c2a98e935f661c95924d8f37
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