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, 11 insertions, 10 deletions

diff --git a/src/backend/optimizer/README b/src/backend/optimizer/README
index f0113dfaf5..e60f145720 100644
--- a/src/backend/optimizer/README
+++ b/src/backend/optimizer/README
@@ -4,11 +4,11 @@ Summary
 These directories take the Query structure returned by the parser, and
 generate a plan used by the executor.  The /plan directory generates the
 actual output plan, the /path code generates all possible ways to join the
-tables, and /prep handles special cases like inheritance.  /util is utility
-stuff.  /geqo is the separate "genetic optimization" planner --- it does
-a semi-random search through the join tree space, rather than exhaustively
-considering all possible join trees.  (But each join considered by /geqo
-is given to /path to create paths for, so we consider all possible
+tables, and /prep handles various preprocessing steps for special cases.
+/util is utility stuff.  /geqo is the separate "genetic optimization" planner
+--- it does a semi-random search through the join tree space, rather than
+exhaustively considering all possible join trees.  (But each join considered
+by /geqo is given to /path to create paths for, so we consider all possible
 implementation paths for each specific join pair even in GEQO mode.)
 
 
@@ -210,10 +210,10 @@ planner()
      thereby reducing the accuracy of selectivity estimates.
  process sublinks
  convert Vars of outer query levels into Params
---union_planner()
-  handle unions and inheritance by mutual recursion with prepunion.c routines
-  preprocess target list
-  handle GROUP BY, HAVING, aggregates, ORDER BY, DISTINCT
+--grouping_planner()
+  preprocess target list for non-SELECT queries
+  handle UNION/INTERSECT/EXCEPT, GROUP BY, HAVING, aggregates,
+	ORDER BY, DISTINCT, LIMIT
 --query_planner()
    pull out constant quals, which can be used to gate execution of the
 	whole plan (if any are found, we make a top-level Result node
@@ -239,11 +239,12 @@ planner()
       Loop back if this wasn't the top join level.
    Back at query_planner:
    put back constant quals and non-simplified target list
- Back at union_planner:
+ Back at grouping_planner:
  do grouping(GROUP)
  do aggregates
  make unique(DISTINCT)
  make sort(ORDER BY)
+ make limit(LIMIT/OFFSET)
 
 
 Optimizer Data Structures