Re: RFC: extensible planner state

Robert Haas <robertmhaas@gmail.com> writes:
> Done now. Here's a rebase of the rest, plus I tweaked the GEQO patch
> to try to avoid a compiler warning that cfbot was complaining about.

I'm good with the v7 patch set, except for the complaint I raised
previously that we really ought to have more than zero documentation
for planner()'s parameters.  If you don't care to write such text,
attached is a cut at it.

            regards, tom lane

diff --git a/src/backend/optimizer/plan/planner.c b/src/backend/optimizer/plan/planner.c
index 41bd8353430..c249f34eb8e 100644
--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -280,6 +280,23 @@ static void create_partial_unique_paths(PlannerInfo *root, RelOptInfo *input_rel
  *
  *       Query optimizer entry point
  *
+ * Inputs:
+ *    parse: an analyzed-and-rewritten query tree for an optimizable statement
+ *    query_string: source text for the query tree (used for error reports)
+ *    cursorOptions: bitmask of CURSOR_OPT_XXX flags, see parsenodes.h
+ *    boundParams: passed-in parameter values, or NULL if none
+ *    es: ExplainState if being called from EXPLAIN, else NULL
+ *
+ * The result is a PlannedStmt tree.
+ *
+ * PARAM_EXTERN Param nodes within the parse tree can be replaced by Consts
+ * using values from boundParams, if those values are marked PARAM_FLAG_CONST.
+ * Parameter values not so marked are still relied on for estimation purposes.
+ *
+ * The ExplainState pointer is not currently used by the core planner, but it
+ * is passed through to some planner hooks so that they can report information
+ * back to EXPLAIN extension hooks.
+ *
  * To support loadable plugins that monitor or modify planner behavior,
  * we provide a hook variable that lets a plugin get control before and
  * after the standard planning process.  The plugin would normally call