From 07cf99ac6fc6d0265efae5cb88c345d7dbcd57fd Mon Sep 17 00:00:00 2001 From: Tom Lane Date: 2007年1月24日 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 4838ef18e6b..b3789d8efcf 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); } -- 2.39.5

AltStyle によって変換されたページ (->オリジナル) /