Restructure handling of inheritance queries so that they work with outer

joins, and clean things up a good deal at the same time.  Append plan node
no longer hacks on rangetable at runtime --- instead, all child tables are
given their own RT entries during planning.  Concept of multiple target
tables pushed up into execMain, replacing bug-prone implementation within
nodeAppend.  Planner now supports generating Append plans for inheritance
sets either at the top of the plan (the old way) or at the bottom.  Expanding
at the bottom is appropriate for tables used as sources, since they may
appear inside an outer join; but we must still expand at the top when the
target of an UPDATE or DELETE is an inheritance set, because we actually need
a different targetlist and junkfilter for each target table in that case.
Fortunately a target table can't be inside an outer join...  Bizarre mutual
recursion between union_planner and prepunion.c is gone --- in fact,
union_planner doesn't really have much to do with union queries anymore,
so I renamed it grouping_planner.

1 files changed, 23 insertions, 1 deletions

diff --git a/src/include/nodes/relation.h b/src/include/nodes/relation.h
index 1c864f2e721..45d53be5f62 100644
--- a/src/include/nodes/relation.h
+++ b/src/include/nodes/relation.h
@@ -7,7 +7,7 @@
  * Portions Copyright (c) 1996-2000, PostgreSQL, Inc
  * Portions Copyright (c) 1994, Regents of the University of California
  *
- * $Id: relation.h,v 1.49 2000/09/29 18:21:39 tgl Exp $
+ * $Id: relation.h,v 1.50 2000/11/12 00:37:01 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -82,6 +82,14 @@ typedef enum CostSelector
  *		upon creation of the RelOptInfo object; they are filled in when
  *		set_base_rel_pathlist processes the object.
  *
+ *		Note: if a base relation is the root of an inheritance tree
+ *		(SELECT FROM foo*) it is still considered a base rel.  We will
+ *		generate a list of candidate Paths for accessing that table itself,
+ *		and also generate baserel RelOptInfo nodes for each child table,
+ *		with their own candidate Path lists.  Then, an AppendPath is built
+ *		from the cheapest Path for each of these tables, and set to be the
+ *		only available Path for the inheritance baserel.
+ *
  *	 * The presence of the remaining fields depends on the restrictions
  *		and joins that the relation participates in:
  *
@@ -313,6 +321,9 @@ typedef struct IndexPath
 	double		rows;			/* estimated number of result tuples */
 } IndexPath;
 
+/*
+ * TidPath represents a scan by TID
+ */
 typedef struct TidPath
 {
 	Path		path;
@@ -321,6 +332,17 @@ typedef struct TidPath
 } TidPath;
 
 /*
+ * AppendPath represents an Append plan, ie, successive execution of
+ * several member plans.  Currently it is only used to handle expansion
+ * of inheritance trees.
+ */
+typedef struct AppendPath
+{
+	Path		path;
+	List	   *subpaths;		/* list of component Paths */
+} AppendPath;
+
+/*
  * All join-type paths share these fields.
  */