IN clauses appearing at top level of WHERE can now be handled as joins.

There are two implementation techniques: the executor understands a new
JOIN_IN jointype, which emits at most one matching row per left-hand row,
or the result of the IN's sub-select can be fed through a DISTINCT filter
and then joined as an ordinary relation.
Along the way, some minor code cleanup in the optimizer; notably, break
out most of the jointree-rearrangement preprocessing in planner.c and
put it in a new file prep/prepjointree.c.

src/backend/optimizer/util/tlist.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $Header: /cvsroot/pgsql/src/backend/optimizer/util/tlist.c,v 1.53 2002/12/12 15:49:32 tgl Exp $
+ *	  $Header: /cvsroot/pgsql/src/backend/optimizer/util/tlist.c,v 1.54 2003/01/20 18:54:57 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -255,3 +255,25 @@ get_sortgroupclause_expr(SortClause *sortClause, List *targetList)
 
 	return (Node *) tle->expr;
 }
+
+/*
+ * get_sortgrouplist_exprs
+ *		Given a list of SortClauses (or GroupClauses), build a list
+ *		of the referenced targetlist expressions.
+ */
+List *
+get_sortgrouplist_exprs(List *sortClauses, List *targetList)
+{
+	List   *result = NIL;
+	List   *l;
+
+	foreach(l, sortClauses)
+	{
+		SortClause *sortcl = (SortClause *) lfirst(l);
+		Node	   *sortexpr;
+
+		sortexpr = get_sortgroupclause_expr(sortcl, targetList);
+		result = lappend(result, sortexpr);
+	}
+	return result;
+}