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.

1 files changed, 12 insertions, 2 deletions

diff --git a/src/backend/executor/execScan.c b/src/backend/executor/execScan.c
index f4d8eba354..538b0faf37 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.34 2004/12/31 21:59:45 pgsql Exp $
+ *	  $PostgreSQL: pgsql/src/backend/executor/execScan.c,v 1.34.4.1 2007/01/24 01:26:02 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -214,8 +214,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);
 	}