1berry/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Repair subselect.c's occasional assignment of the wrong vartypmod to

Browse Source 
Vars created to fill subplan args lists.  This is an ancient error, going
back at least to 7.0, but is more easily triggered in 7.4 than before
because we no longer compare varlevelsup when deciding whether a Param
slot can be re-used.  Fixes bug reported by Klint Gore.
This commit is contained in:
Tom Lane 2003-11-25 23:59:32 +00:00
parent 1230343332
commit d6dd992b4c
1 changed files with 8 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
src/backend/optimizer/plan/subselect.c
View File

@ -7,7 +7,7 @@
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/optimizer/plan/subselect.c,v 1.83 2003/10/18 16:52:15 tgl Exp $
* $Header: /cvsroot/pgsql/src/backend/optimizer/plan/subselect.c,v 1.83.2.1 2003/11/25 23:59:32 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -118,6 +118,11 @@ replace_outer_var(Var *var)
* well, I believe that this sort of aliasing will cause no trouble.
* The correct field should get stored into the Param slot at
* execution in each part of the tree.
*
* We also need to demand a match on vartypmod. This does not matter
* for the Param itself, since those are not typmod-dependent, but it
* does matter when make_subplan() instantiates a modified copy of the
* Var for a subplan's args list.
*/
i = 0;
foreach(ppl, PlannerParamList)
@ -129,7 +134,8 @@ replace_outer_var(Var *var)
if (pvar->varno == var->varno &&
pvar->varattno == var->varattno &&
pvar->vartype == var->vartype)
pvar->vartype == var->vartype &&
pvar->vartypmod == var->vartypmod)
break;
}
i++;