diff --git a/src/backend/executor/execQual.c b/src/backend/executor/execQual.c
index b1d29f3d8e563b8ee0433eeff8b7434df497146a..87eeb835686d1d8d11740ff80c56a9bf1ca5220a 100644
--- a/src/backend/executor/execQual.c
+++ b/src/backend/executor/execQual.c
@@ -7,7 +7,7 @@
  *
  *
  * IDENTIFICATION
- *	  $Header: /cvsroot/pgsql/src/backend/executor/execQual.c,v 1.46 1999/02/23 07:33:44 thomas Exp $
+ *	  $Header: /cvsroot/pgsql/src/backend/executor/execQual.c,v 1.47 1999/03/10 12:16:09 vadim Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -1474,10 +1474,15 @@ ExecTargetList(List *targetlist,
 		 *		is this a new phenomenon? it might cause bogus behavior
 		 *		if we try to free this tuple later!! I put a hook in
 		 *		ExecProject to watch out for this case -mer 24 Aug 1992
+		 *
+		 *		We must return dummy tuple!!! Try 
+		 *		select t1.x from t1, t2 where t1.y = 1 and t2.y = 1
+		 *		- t2 scan target list will be empty and so no one tuple
+		 *		will be returned! But Mer was right - dummy tuple
+		 *		must be palloced...	- vadim 03/01/1999
 		 */
-		CXT1_printf("ExecTargetList: context is %d\n", CurrentMemoryContext);
 		*isDone = true;
-		return (HeapTuple) true;
+		return (HeapTuple) palloc(1);
 	}
 
 	/*
@@ -1640,12 +1645,6 @@ ExecProject(ProjectionInfo *projInfo, bool *isDone)
 	tupValue = projInfo->pi_tupValue;
 	econtext = projInfo->pi_exprContext;
 
-	if (targetlist == NIL)
-	{
-		*isDone = true;
-		return (TupleTableSlot *) NULL;
-	}
-
 	/*
 	 *	form a new (result) tuple
 	 */