From 212df03ac94a1bbb281b4e8ee31007f07682451c Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 24 Jan 2007 01:25:56 +0000 Subject: [PATCH] Relax an Assert() that has been found to be too strict in some situations involving unions of types having typmods. Variants of the failure are known to occur in 8.1 and up; not sure if it's possible in 8.0 and 7.4, but since the code exists that far back, I'll just patch 'em all. Per report from Brian Hurt. --- src/backend/executor/execScan.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/src/backend/executor/execScan.c b/src/backend/executor/execScan.c index 90ffda092a0..45ef7c3ef82 100644 --- a/src/backend/executor/execScan.c +++ b/src/backend/executor/execScan.c @@ -12,7 +12,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/executor/execScan.c,v 1.37 2005/10/15 02:49:16 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/executor/execScan.c,v 1.37.2.1 2007/01/24 01:25:56 tgl Exp $ * *------------------------------------------------------------------------- */ @@ -215,8 +215,18 @@ tlist_matches_tupdesc(PlanState *ps, List *tlist, Index varno, TupleDesc tupdesc return false; /* out of order */ if (att_tup->attisdropped) return false; /* table contains dropped columns */ + /* + * Note: usually the Var's type should match the tupdesc exactly, + * but in situations involving unions of columns that have different + * typmods, the Var may have come from above the union and hence have + * typmod -1. This is a legitimate situation since the Var still + * describes the column, just not as exactly as the tupdesc does. + * We could change the planner to prevent it, but it'd then insert + * projection steps just to convert from specific typmod to typmod -1, + * which is pretty silly. + */ Assert(var->vartype == att_tup->atttypid); - Assert(var->vartypmod == att_tup->atttypmod); + Assert(var->vartypmod == att_tup->atttypmod || var->vartypmod == -1); tlist_item = lnext(tlist_item); }