]> git.ipfire.org Git - thirdparty/postgresql.git/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:03 +0000 (17:31 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Fri, 23 Aug 2013 21:31:03 +0000 (17:31 -0400)
commitf7bbd46dcfb057459f467da1b0385ae6c13e5977
tree4903d4b71fb6ae431f268528b520ca9c2a073d4c
parent649839dd9f1c08b7aadb654587edd9f86a3caa3f
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