Ensure that the result tuple of an EvalPlanQual cycle gets materialized

before we zap the input tuple.  Otherwise, pass-by-reference columns of
the result slot are likely to contain just references to the input
tuple, leading to big trouble if the pfree'd space is reused.  Per
trouble report from Jaime Casanova.  This is a new bug in the recent
rewrite of EvalPlanQual, so nothing to back-patch.

src/backend/executor/execMain.c

@@ -26,7 +26,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/executor/execMain.c,v 1.336 2009/12/09 21:57:51 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/executor/execMain.c,v 1.337 2009/12/11 18:14:43 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -1407,6 +1407,16 @@ EvalPlanQual(EState *estate, EPQState *epqstate,
 	 */
 	slot = EvalPlanQualNext(epqstate);
 
+	/*
+	 * If we got a tuple, force the slot to materialize the tuple so that
+	 * it is not dependent on any local state in the EPQ query (in particular,
+	 * it's highly likely that the slot contains references to any pass-by-ref
+	 * datums that may be present in copyTuple).  As with the next step,
+	 * this is to guard against early re-use of the EPQ query.
+	 */
+	if (!TupIsNull(slot))
+		(void) ExecMaterializeSlot(slot);
+
 	/*
 	 * Clear out the test tuple.  This is needed in case the EPQ query
 	 * is re-used to test a tuple for a different relation.  (Not clear