From 07cf99ac6fc6d0265efae5cb88c345d7dbcd57fd Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 24 Jan 2007 01:25:47 +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 4838ef18e6..b3789d8efc 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.39 2007/01/05 22:19:27 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/executor/execScan.c,v 1.40 2007/01/24 01:25:47 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); }