From c60125a9be51f98cdcda8de264f5bccf106788d8 Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 6 Feb 2007 17:35:34 +0000
Subject: [PATCH] Remove typmod checking from the recent security-related
 patches.  It turns out that ExecEvalVar and friends don't necessarily have
 access to a tuple descriptor with correct typmod: it definitely can contain
 -1, and possibly might contain other values that are different from the Var's
 value. Arguably this should be cleaned up someday, but it's not a simple
 change, and in any case typmod discrepancies don't pose a security hazard.
 Per reports from numerous people :-(

I'm not entirely sure whether the failure can occur in 8.0 --- the simple
test cases reported so far don't trigger it there.  But back-patch the
change all the way anyway.
---
 src/backend/executor/execQual.c  | 18 +++++++++---------
 src/backend/executor/execUtils.c |  7 ++-----
 2 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/src/backend/executor/execQual.c b/src/backend/executor/execQual.c
index e063814aad9..06fe23e6376 100644
--- a/src/backend/executor/execQual.c
+++ b/src/backend/executor/execQual.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/executor/execQual.c,v 1.183.2.5 2007/02/02 00:07:44 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/executor/execQual.c,v 1.183.2.6 2007/02/06 17:35:34 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -497,8 +497,11 @@ ExecEvalVar(ExprState *exprstate, ExprContext *econtext,
 		 * Note: we allow a reference to a dropped attribute.  slot_getattr
 		 * will force a NULL result in such cases.
 		 *
-		 * Note: we check typmod, but allow the case that the Var has
-		 * unspecified typmod while the column has a specific typmod.
+		 * Note: ideally we'd check typmod as well as typid, but that seems
+		 * impractical at the moment: in many cases the tupdesc will have
+		 * been generated by ExecTypeFromTL(), and that can't guarantee to
+		 * generate an accurate typmod in all cases, because some expression
+		 * node types don't carry typmod.
 		 */
 		if (attnum > 0)
 		{
@@ -514,9 +517,7 @@ ExecEvalVar(ExprState *exprstate, ExprContext *econtext,
 			/* can't check type if dropped, since atttypid is probably 0 */
 			if (!attr->attisdropped)
 			{
-				if (variable->vartype != attr->atttypid ||
-					(variable->vartypmod != attr->atttypmod &&
-					 variable->vartypmod != -1))
+				if (variable->vartype != attr->atttypid)
 					ereport(ERROR,
 							(errmsg("attribute %d has wrong type", attnum),
 							 errdetail("Table has type %s, but query expects %s.",
@@ -2871,9 +2872,8 @@ ExecEvalFieldSelect(FieldSelectState *fstate,
 	}
 
 	/* Check for type mismatch --- possible after ALTER COLUMN TYPE? */
-	if (fselect->resulttype != attr->atttypid ||
-		(fselect->resulttypmod != attr->atttypmod &&
-		 fselect->resulttypmod != -1))
+	/* As in ExecEvalVar, we should but can't check typmod */
+	if (fselect->resulttype != attr->atttypid)
 		ereport(ERROR,
 				(errmsg("attribute %d has wrong type", fieldnum),
 				 errdetail("Table has type %s, but query expects %s.",
diff --git a/src/backend/executor/execUtils.c b/src/backend/executor/execUtils.c
index a2d3543ced0..e7e8a4d1101 100644
--- a/src/backend/executor/execUtils.c
+++ b/src/backend/executor/execUtils.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/executor/execUtils.c,v 1.126.2.4 2007/02/02 00:07:44 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/executor/execUtils.c,v 1.126.2.5 2007/02/06 17:35:34 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -537,10 +537,7 @@ ExecBuildProjectionInfo(List *targetList,
 			break;
 		}
 		attr = inputDesc->attrs[variable->varattno - 1];
-		if (attr->attisdropped ||
-			variable->vartype != attr->atttypid ||
-			(variable->vartypmod != attr->atttypmod &&
-			 variable->vartypmod != -1))
+		if (attr->attisdropped || variable->vartype != attr->atttypid)
 		{
 			isVarList = false;
 			break;