Lobotomize typmod check in convert_tuples_by_position, back branches only.

convert_tuples_by_position was rejecting attempts to coerce a record field
with -1 typmod to the same type with a non-default typmod.  This is in fact
the "correct" thing to do (since we're just going to do a type relabeling,
not invoke any length-conversion cast function); but it results in
rejecting valid cases like bug #6020, because the source record's tupdesc
is built from Params that don't have typmod assigned.  Since that's a
regression from previous versions, which accepted this code, we have to do
something about it.  In HEAD, I've fixed the problem properly by causing
the Params to receive the correct typmods; but the potential for incidental
behavioral changes seems high enough to make it unattractive to make the
same change in released branches.  (And it couldn't be fixed that way in
8.4 anyway...)  Hence this patch just modifies convert_tuples_by_position
to not complain if either the input or the output tupdesc has typmod -1.
This is still a shade tighter checking than we did before 9.0, since before
that plpgsql failed to consider typmods at all when checking record
compatibility.  (convert_tuples_by_position is currently used only by
plpgsql, so we're not affecting other behavior.)

Back-patch to 8.4, since we recently back-ported convert_tuples_by_position
into that branch.

src/backend/access/common/tupconvert.c

@@ -100,7 +100,8 @@ convert_tuples_by_position(TupleDesc indesc,
 			nincols++;
 			/* Found matching column, check type */
 			if (atttypid != att->atttypid ||
-				(atttypmod != att->atttypmod && atttypmod >= 0))
+				(atttypmod != att->atttypmod && atttypmod >= 0 &&
+				 att->atttypmod >= 0))
 				ereport(ERROR,
 						(errcode(ERRCODE_DATATYPE_MISMATCH),
 						 errmsg_internal("%s", _(msg)),