Re-run pgindent, fixing a problem where comment lines after a blank

comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
2025-09-09 13:09:39 +03:00 · 2005-11-22 18:23:31 +00:00
parent c8de36352f
commit bef7764835
234 changed files with 2570 additions and 2543 deletions
--- a/src/backend/optimizer/geqo/geqo_eval.c
+++ b/src/backend/optimizer/geqo/geqo_eval.c
@@ -6,7 +6,7 @@
 * Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group
 * Portions Copyright (c) 1994, Regents of the University of California
 *
- * $PostgreSQL: pgsql/src/backend/optimizer/geqo/geqo_eval.c,v 1.77 2005/10/15 02:49:19 momjian Exp $
+ * $PostgreSQL: pgsql/src/backend/optimizer/geqo/geqo_eval.c,v 1.77.2.1 2005/11/22 18:23:10 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -89,10 +89,10 @@ geqo_eval(Gene *tour, int num_gene, GeqoEvalData *evaldata)
 	 * truncating the list to its original length.	NOTE this assumes that any
 	 * added entries are appended at the end!
 	 *
-	 * We also must take care not to mess up the outer join_rel_hash, if there is
-	 * one.  We can do this by just temporarily setting the link to NULL.  (If
-	 * we are dealing with enough join rels, which we very likely are, a new
-	 * hash table will get built and used locally.)
+	 * We also must take care not to mess up the outer join_rel_hash, if there
+	 * is one.	We can do this by just temporarily setting the link to NULL.
+	 * (If we are dealing with enough join rels, which we very likely are, a
+	 * new hash table will get built and used locally.)
 	 */
 	savelength = list_length(evaldata->root->join_rel_list);
 	savehash = evaldata->root->join_rel_hash;
@@ -182,9 +182,9 @@ gimme_tree(Gene *tour, int num_gene, GeqoEvalData *evaldata)
 	 * tour other than the one given.  To the extent that the heuristics are
 	 * helpful, however, this will be a better plan than the raw tour.
 	 *
-	 * Also, when a join attempt fails (because of IN-clause constraints), we may
-	 * be able to recover and produce a workable plan, where the old code just
-	 * had to give up.	This case acts the same as a false result from
+	 * Also, when a join attempt fails (because of IN-clause constraints), we
+	 * may be able to recover and produce a workable plan, where the old code
+	 * just had to give up.  This case acts the same as a false result from
 	 * desirable_join().
 	 */
 	for (rel_count = 0; rel_count < num_gene; rel_count++)
--- a/src/backend/optimizer/geqo/geqo_pool.c
+++ b/src/backend/optimizer/geqo/geqo_pool.c
@@ -6,7 +6,7 @@
 * Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group
 * Portions Copyright (c) 1994, Regents of the University of California
 *
- * $PostgreSQL: pgsql/src/backend/optimizer/geqo/geqo_pool.c,v 1.27 2005/10/15 02:49:19 momjian Exp $
+ * $PostgreSQL: pgsql/src/backend/optimizer/geqo/geqo_pool.c,v 1.27.2.1 2005/11/22 18:23:10 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -99,9 +99,9 @@ random_init_pool(Pool *pool, GeqoEvalData *evaldata)
 	 * We immediately discard any invalid individuals (those that geqo_eval
 	 * returns DBL_MAX for), thereby not wasting pool space on them.
 	 *
-	 * If we fail to make any valid individuals after 10000 tries, give up; this
-	 * probably means something is broken, and we shouldn't just let ourselves
-	 * get stuck in an infinite loop.
+	 * If we fail to make any valid individuals after 10000 tries, give up;
+	 * this probably means something is broken, and we shouldn't just let
+	 * ourselves get stuck in an infinite loop.
 	 */
 	i = 0;
 	while (i < pool->size)
--- a/src/backend/optimizer/path/allpaths.c
+++ b/src/backend/optimizer/path/allpaths.c
@@ -8,7 +8,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/path/allpaths.c,v 1.137 2005/10/15 02:49:19 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/path/allpaths.c,v 1.137.2.1 2005/11/22 18:23:10 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -440,8 +440,8 @@ set_subquery_pathlist(PlannerInfo *root, RelOptInfo *rel,
 	 * Restrictions on individual clauses are checked by
 	 * qual_is_pushdown_safe().
 	 *
-	 * Non-pushed-down clauses will get evaluated as qpquals of the SubqueryScan
-	 * node.
+	 * Non-pushed-down clauses will get evaluated as qpquals of the
+	 * SubqueryScan node.
 	 *
 	 * XXX Are there any cases where we want to make a policy decision not to
 	 * push down a pushable qual, because it'd result in a worse plan?
--- a/src/backend/optimizer/path/costsize.c
+++ b/src/backend/optimizer/path/costsize.c
@@ -49,7 +49,7 @@
 * Portions Copyright (c) 1994, Regents of the University of California
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/path/costsize.c,v 1.149 2005/10/15 02:49:19 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/path/costsize.c,v 1.149.2.1 2005/11/22 18:23:10 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -155,8 +155,8 @@ cost_seqscan(Path *path, PlannerInfo *root,
 	/*
 	 * disk costs
 	 *
-	 * The cost of reading a page sequentially is 1.0, by definition. Note that
-	 * the Unix kernel will typically do some amount of read-ahead
+	 * The cost of reading a page sequentially is 1.0, by definition. Note
+	 * that the Unix kernel will typically do some amount of read-ahead
 	 * optimization, so that this cost is less than the true cost of reading a
 	 * page from disk.	We ignore that issue here, but must take it into
 	 * account when estimating the cost of non-sequential accesses!
@@ -480,8 +480,8 @@ cost_bitmap_heap_scan(Path *path, PlannerInfo *root, RelOptInfo *baserel,
 	/*
 	 * Estimate CPU costs per tuple.
 	 *
-	 * Often the indexquals don't need to be rechecked at each tuple ... but not
-	 * always, especially not if there are enough tuples involved that the
+	 * Often the indexquals don't need to be rechecked at each tuple ... but
+	 * not always, especially not if there are enough tuples involved that the
 	 * bitmaps become lossy.  For the moment, just assume they will be
 	 * rechecked always.
 	 */
@@ -869,13 +869,14 @@ cost_agg(Path *path, PlannerInfo *root,
 	 * We will produce a single output tuple if not grouping, and a tuple per
 	 * group otherwise.  We charge cpu_tuple_cost for each output tuple.
 	 *
-	 * Note: in this cost model, AGG_SORTED and AGG_HASHED have exactly the same
-	 * total CPU cost, but AGG_SORTED has lower startup cost.  If the input
-	 * path is already sorted appropriately, AGG_SORTED should be preferred
-	 * (since it has no risk of memory overflow).  This will happen as long as
-	 * the computed total costs are indeed exactly equal --- but if there's
-	 * roundoff error we might do the wrong thing.	So be sure that the
-	 * computations below form the same intermediate values in the same order.
+	 * Note: in this cost model, AGG_SORTED and AGG_HASHED have exactly the
+	 * same total CPU cost, but AGG_SORTED has lower startup cost.	If the
+	 * input path is already sorted appropriately, AGG_SORTED should be
+	 * preferred (since it has no risk of memory overflow).  This will happen
+	 * as long as the computed total costs are indeed exactly equal --- but if
+	 * there's roundoff error we might do the wrong thing.  So be sure that
+	 * the computations below form the same intermediate values in the same
+	 * order.
 	 */
 	if (aggstrategy == AGG_PLAIN)
 	{
@@ -1074,8 +1075,8 @@ cost_mergejoin(MergePath *path, PlannerInfo *root)
 	 * restriction clauses) separately.  We use approx_selectivity here for
 	 * speed --- in most cases, any errors won't affect the result much.
 	 *
-	 * Note: it's probably bogus to use the normal selectivity calculation here
-	 * when either the outer or inner path is a UniquePath.
+	 * Note: it's probably bogus to use the normal selectivity calculation
+	 * here when either the outer or inner path is a UniquePath.
 	 */
 	merge_selec = approx_selectivity(root, mergeclauses,
 									 path->jpath.jointype);
@@ -1095,22 +1096,22 @@ cost_mergejoin(MergePath *path, PlannerInfo *root)
 	 * but on the other hand we ignore the bookkeeping costs of mark/restore.
 	 * Not clear if it's worth developing a more refined model.
 	 *
-	 * The number of re-fetches can be estimated approximately as size of merge
-	 * join output minus size of inner relation.  Assume that the distinct key
-	 * values are 1, 2, ..., and denote the number of values of each key in
-	 * the outer relation as m1, m2, ...; in the inner relation, n1, n2, ...
-	 * Then we have
+	 * The number of re-fetches can be estimated approximately as size of
+	 * merge join output minus size of inner relation.	Assume that the
+	 * distinct key values are 1, 2, ..., and denote the number of values of
+	 * each key in the outer relation as m1, m2, ...; in the inner relation,
+	 * n1, n2, ... Then we have
 	 *
 	 * size of join = m1 * n1 + m2 * n2 + ...
 	 *
-	 * number of rescanned tuples = (m1 - 1) * n1 + (m2 - 1) * n2 + ... = m1 * n1
-	 * + m2 * n2 + ... - (n1 + n2 + ...) = size of join - size of inner
+	 * number of rescanned tuples = (m1 - 1) * n1 + (m2 - 1) * n2 + ... = m1 *
+	 * n1 + m2 * n2 + ... - (n1 + n2 + ...) = size of join - size of inner
 	 * relation
 	 *
-	 * This equation works correctly for outer tuples having no inner match (nk =
-	 * 0), but not for inner tuples having no outer match (mk = 0); we are
-	 * effectively subtracting those from the number of rescanned tuples, when
-	 * we should not.  Can we do better without expensive selectivity
+	 * This equation works correctly for outer tuples having no inner match
+	 * (nk = 0), but not for inner tuples having no outer match (mk = 0); we
+	 * are effectively subtracting those from the number of rescanned tuples,
+	 * when we should not.	Can we do better without expensive selectivity
 	 * computations?
 	 */
 	if (IsA(outer_path, UniquePath))
@@ -1132,9 +1133,9 @@ cost_mergejoin(MergePath *path, PlannerInfo *root)
 	 * inputs that will actually need to be scanned. We use only the first
 	 * (most significant) merge clause for this purpose.
 	 *
-	 * Since this calculation is somewhat expensive, and will be the same for all
-	 * mergejoin paths associated with the merge clause, we cache the results
-	 * in the RestrictInfo node.
+	 * Since this calculation is somewhat expensive, and will be the same for
+	 * all mergejoin paths associated with the merge clause, we cache the
+	 * results in the RestrictInfo node.
 	 */
 	if (mergeclauses && path->jpath.jointype != JOIN_FULL)
 	{
@@ -1300,8 +1301,8 @@ cost_hashjoin(HashPath *path, PlannerInfo *root)
 	 * restriction clauses) separately.  We use approx_selectivity here for
 	 * speed --- in most cases, any errors won't affect the result much.
 	 *
-	 * Note: it's probably bogus to use the normal selectivity calculation here
-	 * when either the outer or inner path is a UniquePath.
+	 * Note: it's probably bogus to use the normal selectivity calculation
+	 * here when either the outer or inner path is a UniquePath.
 	 */
 	hash_selec = approx_selectivity(root, hashclauses,
 									path->jpath.jointype);
@@ -1341,8 +1342,8 @@ cost_hashjoin(HashPath *path, PlannerInfo *root)
 	 * bucketsize estimated for any individual hashclause; this is undoubtedly
 	 * conservative.
 	 *
-	 * BUT: if inner relation has been unique-ified, we can assume it's good for
-	 * hashing.  This is important both because it's the right answer, and
+	 * BUT: if inner relation has been unique-ified, we can assume it's good
+	 * for hashing.  This is important both because it's the right answer, and
 	 * because we avoid contaminating the cache with a value that's wrong for
 	 * non-unique-ified paths.
 	 */
@@ -1538,8 +1539,8 @@ cost_qual_eval_walker(Node *node, QualCost *total)
 	 * and so are boolean operators (AND, OR, NOT). Simplistic, but a lot
 	 * better than no model at all.
 	 *
-	 * Should we try to account for the possibility of short-circuit evaluation
-	 * of AND/OR?
+	 * Should we try to account for the possibility of short-circuit
+	 * evaluation of AND/OR?
 	 */
 	if (IsA(node, FuncExpr) ||
 		IsA(node, OpExpr) ||
@@ -1564,8 +1565,8 @@ cost_qual_eval_walker(Node *node, QualCost *total)
 		 * (Sub-selects that can be executed as InitPlans have already been
 		 * removed from the expression.)
 		 *
-		 * An exception occurs when we have decided we can implement the subplan
-		 * by hashing.
+		 * An exception occurs when we have decided we can implement the
+		 * subplan by hashing.
 		 *
 		 */
 		SubPlan    *subplan = (SubPlan *) node;
@@ -1760,12 +1761,12 @@ set_joinrel_size_estimates(PlannerInfo *root, RelOptInfo *rel,
 	/*
 	 * Basically, we multiply size of Cartesian product by selectivity.
 	 *
-	 * If we are doing an outer join, take that into account: the output must be
-	 * at least as large as the non-nullable input.  (Is there any chance of
-	 * being even smarter?)
+	 * If we are doing an outer join, take that into account: the output must
+	 * be at least as large as the non-nullable input.	(Is there any chance
+	 * of being even smarter?)
 	 *
-	 * For JOIN_IN and variants, the Cartesian product is figured with respect to
-	 * a unique-ified input, and then we can clamp to the size of the other
+	 * For JOIN_IN and variants, the Cartesian product is figured with respect
+	 * to a unique-ified input, and then we can clamp to the size of the other
 	 * input.
 	 */
 	switch (jointype)
@@ -1893,8 +1894,8 @@ set_function_size_estimates(PlannerInfo *root, RelOptInfo *rel)
 	/*
 	 * Estimate number of rows the function itself will return.
 	 *
-	 * XXX no idea how to do this yet; but we can at least check whether function
-	 * returns set or not...
+	 * XXX no idea how to do this yet; but we can at least check whether
+	 * function returns set or not...
 	 */
 	if (expression_returns_set(rte->funcexpr))
 		rel->tuples = 1000;
--- a/src/backend/optimizer/path/indxpath.c
+++ b/src/backend/optimizer/path/indxpath.c
@@ -9,7 +9,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/path/indxpath.c,v 1.191.2.1 2005/11/14 23:54:35 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/path/indxpath.c,v 1.191.2.2 2005/11/22 18:23:10 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -262,8 +262,8 @@ find_usable_indexes(PlannerInfo *root, RelOptInfo *rel,
 		 * to imply the predicate.	If so, we could use the index in the
 		 * current context.
 		 *
-		 * We set useful_predicate to true iff the predicate was proven using the
-		 * current set of clauses.	This is needed to prevent matching a
+		 * We set useful_predicate to true iff the predicate was proven using
+		 * the current set of clauses.	This is needed to prevent matching a
 		 * predOK index to an arm of an OR, which would be a legal but
 		 * pointlessly inefficient plan.  (A better plan will be generated by
 		 * just scanning the predOK index alone, no OR.)
@@ -524,19 +524,19 @@ choose_bitmap_and(PlannerInfo *root, RelOptInfo *rel, List *paths)
 	 * always take the first, and sequentially add on paths that result in a
 	 * lower estimated cost.
 	 *
-	 * We also make some effort to detect directly redundant input paths, as can
-	 * happen if there are multiple possibly usable indexes.  For this we look
-	 * only at plain IndexPath inputs, not at sub-OR clauses. And we consider
-	 * an index redundant if all its index conditions were already used by
-	 * earlier indexes.  (We could use predicate_implied_by to have a more
-	 * intelligent, but much more expensive, check --- but in most cases
+	 * We also make some effort to detect directly redundant input paths, as
+	 * can happen if there are multiple possibly usable indexes.  For this we
+	 * look only at plain IndexPath inputs, not at sub-OR clauses. And we
+	 * consider an index redundant if all its index conditions were already
+	 * used by earlier indexes.  (We could use predicate_implied_by to have a
+	 * more intelligent, but much more expensive, check --- but in most cases
 	 * simple pointer equality should suffice, since after all the index
 	 * conditions are all coming from the same RestrictInfo lists.)
 	 *
-	 * XXX is there any risk of throwing away a useful partial index here because
-	 * we don't explicitly look at indpred?  At least in simple cases, the
-	 * partial index will sort before competing non-partial indexes and so it
-	 * makes the right choice, but perhaps we need to work harder.
+	 * XXX is there any risk of throwing away a useful partial index here
+	 * because we don't explicitly look at indpred?  At least in simple cases,
+	 * the partial index will sort before competing non-partial indexes and so
+	 * it makes the right choice, but perhaps we need to work harder.
 	 *
 	 * Note: outputting the selected sub-paths in selectivity order is a good
 	 * thing even if we weren't using that as part of the selection method,
@@ -920,8 +920,8 @@ check_partial_indexes(PlannerInfo *root, RelOptInfo *rel)
 	 * index.  For now, the test only uses restriction clauses (those in
 	 * baserestrictinfo). --Nels, Dec '92
 	 *
-	 * XXX as of 7.1, equivalence class info *is* available.  Consider improving
-	 * this code as foreseen by Nels.
+	 * XXX as of 7.1, equivalence class info *is* available.  Consider
+	 * improving this code as foreseen by Nels.
 	 */

 	foreach(ilist, rel->indexlist)
--- a/src/backend/optimizer/path/joinpath.c
+++ b/src/backend/optimizer/path/joinpath.c
@@ -8,7 +8,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/path/joinpath.c,v 1.97 2005/10/25 20:30:30 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/path/joinpath.c,v 1.97.2.1 2005/11/22 18:23:10 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -176,8 +176,8 @@ sort_inner_and_outer(PlannerInfo *root,
 	 * cheapest-startup-cost input paths later, and only if they don't need a
 	 * sort.
 	 *
-	 * If unique-ification is requested, do it and then handle as a plain inner
-	 * join.
+	 * If unique-ification is requested, do it and then handle as a plain
+	 * inner join.
 	 */
 	outer_path = outerrel->cheapest_total_path;
 	inner_path = innerrel->cheapest_total_path;
@@ -512,8 +512,8 @@ match_unsorted_outer(PlannerInfo *root,

 		/*
 		 * Generate a mergejoin on the basis of sorting the cheapest inner.
-		 * Since a sort will be needed, only cheapest total cost matters.
-		 * (But create_mergejoin_path will do the right thing if
+		 * Since a sort will be needed, only cheapest total cost matters. (But
+		 * create_mergejoin_path will do the right thing if
 		 * inner_cheapest_total is already correctly sorted.)
 		 */
 		add_path(joinrel, (Path *)
@@ -804,9 +804,9 @@ select_mergejoin_clauses(RelOptInfo *joinrel,

 		/*
 		 * If processing an outer join, only use its own join clauses in the
-		 * merge.  For inner joins we can use pushed-down clauses too.
-		 * (Note: we don't set have_nonmergeable_joinclause here because
-		 * pushed-down clauses will become otherquals not joinquals.)
+		 * merge.  For inner joins we can use pushed-down clauses too. (Note:
+		 * we don't set have_nonmergeable_joinclause here because pushed-down
+		 * clauses will become otherquals not joinquals.)
 		 */
 		if (isouterjoin && restrictinfo->is_pushed_down)
 			continue;
--- a/src/backend/optimizer/path/joinrels.c
+++ b/src/backend/optimizer/path/joinrels.c
@@ -8,7 +8,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/path/joinrels.c,v 1.76 2005/10/15 02:49:20 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/path/joinrels.c,v 1.76.2.1 2005/11/22 18:23:10 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -496,8 +496,9 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2,
 			 * innerrel is exactly RHS; conversely JOIN_REVERSE_IN handles
 			 * RHS/LHS.
 			 *
-			 * JOIN_UNIQUE_OUTER will work if outerrel is exactly RHS; conversely
-			 * JOIN_UNIQUE_INNER will work if innerrel is exactly RHS.
+			 * JOIN_UNIQUE_OUTER will work if outerrel is exactly RHS;
+			 * conversely JOIN_UNIQUE_INNER will work if innerrel is exactly
+			 * RHS.
 			 *
 			 * But none of these will work if we already found another IN that
 			 * needs to trigger here.
--- a/src/backend/optimizer/path/orindxpath.c
+++ b/src/backend/optimizer/path/orindxpath.c
@@ -8,7 +8,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/path/orindxpath.c,v 1.75.2.1 2005/11/14 23:54:35 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/path/orindxpath.c,v 1.75.2.2 2005/11/22 18:23:10 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -91,11 +91,10 @@ create_or_index_quals(PlannerInfo *root, RelOptInfo *rel)

 	/*
 	 * Find potentially interesting OR joinclauses.  Note we must ignore any
-	 * joinclauses that are marked outerjoin_delayed, because they cannot
-	 * be pushed down to the per-relation level due to outer-join rules.
-	 * (XXX in some cases it might be possible to allow this, but it would
-	 * require substantially more bookkeeping about where the clause came
-	 * from.)
+	 * joinclauses that are marked outerjoin_delayed, because they cannot be
+	 * pushed down to the per-relation level due to outer-join rules. (XXX in
+	 * some cases it might be possible to allow this, but it would require
+	 * substantially more bookkeeping about where the clause came from.)
 	 */
 	foreach(i, rel->joininfo)
 	{
--- a/src/backend/optimizer/path/pathkeys.c
+++ b/src/backend/optimizer/path/pathkeys.c
@@ -11,7 +11,7 @@
 * Portions Copyright (c) 1994, Regents of the University of California
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/path/pathkeys.c,v 1.73 2005/10/15 02:49:20 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/path/pathkeys.c,v 1.73.2.1 2005/11/22 18:23:10 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -125,8 +125,8 @@ add_equijoined_keys(PlannerInfo *root, RestrictInfo *restrictinfo)
 	 * structure.  If we find both of them in the same equivalence set to
 	 * start with, we can quit immediately.
 	 *
-	 * This is a standard UNION-FIND problem, for which there exist better data
-	 * structures than simple lists.  If this code ever proves to be a
+	 * This is a standard UNION-FIND problem, for which there exist better
+	 * data structures than simple lists.  If this code ever proves to be a
 	 * bottleneck then it could be sped up --- but for now, simple is
 	 * beautiful.
 	 */
@@ -255,9 +255,9 @@ generate_implied_equalities(PlannerInfo *root)
 		 * Match each item in the set with all that appear after it (it's
 		 * sufficient to generate A=B, need not process B=A too).
 		 *
-		 * A set containing only two items cannot imply any equalities beyond the
-		 * one that created the set, so we can skip this processing in that
-		 * case.
+		 * A set containing only two items cannot imply any equalities beyond
+		 * the one that created the set, so we can skip this processing in
+		 * that case.
 		 */
 		if (nitems >= 3)
 		{
@@ -516,12 +516,12 @@ sub_generate_join_implications(PlannerInfo *root,
 			 * the join clause, since both were automatically generated in the
 			 * cases we care about.
 			 *
-			 * XXX currently this may fail to match in cross-type cases because
-			 * the COALESCE will contain typecast operations while the join
-			 * clause may not (if there is a cross-type mergejoin operator
-			 * available for the two column types). Is it OK to strip implicit
-			 * coercions from the COALESCE arguments?  What of the sortops in
-			 * such cases?
+			 * XXX currently this may fail to match in cross-type cases
+			 * because the COALESCE will contain typecast operations while the
+			 * join clause may not (if there is a cross-type mergejoin
+			 * operator available for the two column types). Is it OK to strip
+			 * implicit coercions from the COALESCE arguments?	What of the
+			 * sortops in such cases?
 			 */
 			if (equal(leftop, cfirst) &&
 				equal(rightop, csecond) &&
@@ -1151,8 +1151,8 @@ build_join_pathkeys(PlannerInfo *root,
 	 * here!  The inner-rel vars we used to need to add are *already* part of
 	 * the outer pathkey!
 	 *
-	 * We do, however, need to truncate the pathkeys list, since it may contain
-	 * pathkeys that were useful for forming this joinrel but are
+	 * We do, however, need to truncate the pathkeys list, since it may
+	 * contain pathkeys that were useful for forming this joinrel but are
 	 * uninteresting to higher levels.
 	 */
 	return truncate_useless_pathkeys(root, joinrel, outer_pathkeys);
@@ -1299,8 +1299,8 @@ find_mergeclauses_for_pathkeys(PlannerInfo *root,
 		 * any redundant mergeclauses from the input list. However, in
 		 * outer-join scenarios there might be multiple matches. An example is
 		 *
-		 * select * from a full join b on a.v1 = b.v1 and a.v2 = b.v2 and a.v1 =
-		 * b.v2;
+		 * select * from a full join b on a.v1 = b.v1 and a.v2 = b.v2 and a.v1
+		 * = b.v2;
 		 *
 		 * Given the pathkeys ((a.v1), (a.v2)) it is okay to return all three
 		 * clauses (in the order a.v1=b.v1, a.v1=b.v2, a.v2=b.v2) and indeed
--- a/src/backend/optimizer/plan/createplan.c
+++ b/src/backend/optimizer/plan/createplan.c
@@ -10,7 +10,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/plan/createplan.c,v 1.202 2005/10/19 17:31:20 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/plan/createplan.c,v 1.202.2.1 2005/11/22 18:23:10 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -325,7 +325,7 @@ use_physical_tlist(RelOptInfo *rel)

 	/*
 	 * Can't do it if any system columns or whole-row Vars are requested,
-	 * either.  (This could possibly be fixed but would take some fragile
+	 * either.	(This could possibly be fixed but would take some fragile
 	 * assumptions in setrefs.c, I think.)
 	 */
 	for (i = rel->min_attr; i <= 0; i++)
@@ -1251,8 +1251,8 @@ create_nestloop_plan(PlannerInfo *root,
 		 * caught this case because the join clauses would never have been put
 		 * in the same joininfo list.
 		 *
-		 * We can skip this if the index path is an ordinary indexpath and not a
-		 * special innerjoin path.
+		 * We can skip this if the index path is an ordinary indexpath and not
+		 * a special innerjoin path.
 		 */
 		IndexPath  *innerpath = (IndexPath *) best_path->innerjoinpath;

@@ -1270,13 +1270,13 @@ create_nestloop_plan(PlannerInfo *root,
 		/*
 		 * Same deal for bitmapped index scans.
 		 *
-		 * Note: both here and above, we ignore any implicit index restrictions
-		 * associated with the use of partial indexes.	This is OK because
-		 * we're only trying to prove we can dispense with some join quals;
-		 * failing to prove that doesn't result in an incorrect plan.  It is
-		 * the right way to proceed because adding more quals to the stuff we
-		 * got from the original query would just make it harder to detect
-		 * duplication.
+		 * Note: both here and above, we ignore any implicit index
+		 * restrictions associated with the use of partial indexes.  This is
+		 * OK because we're only trying to prove we can dispense with some
+		 * join quals; failing to prove that doesn't result in an incorrect
+		 * plan.  It is the right way to proceed because adding more quals to
+		 * the stuff we got from the original query would just make it harder
+		 * to detect duplication.
 		 */
 		BitmapHeapPath *innerpath = (BitmapHeapPath *) best_path->innerjoinpath;

@@ -1547,8 +1547,9 @@ fix_indexqual_references(List *indexquals, IndexPath *index_path,
 		/*
 		 * Make a copy that will become the fixed clause.
 		 *
-		 * We used to try to do a shallow copy here, but that fails if there is a
-		 * subplan in the arguments of the opclause.  So just do a full copy.
+		 * We used to try to do a shallow copy here, but that fails if there
+		 * is a subplan in the arguments of the opclause.  So just do a full
+		 * copy.
 		 */
 		newclause = (OpExpr *) copyObject((Node *) clause);

@@ -2232,8 +2233,8 @@ make_sort_from_pathkeys(PlannerInfo *root, Plan *lefttree, List *pathkeys)
 		 * available Var in the tlist.	If there isn't any, use the first one
 		 * that is an expression in the input's vars.
 		 *
-		 * XXX if we have a choice, is there any way of figuring out which might
-		 * be cheapest to execute?	(For example, int4lt is likely much
+		 * XXX if we have a choice, is there any way of figuring out which
+		 * might be cheapest to execute?  (For example, int4lt is likely much
 		 * cheaper to execute than numericlt, but both might appear in the
 		 * same pathkey sublist...)  Not clear that we ever will have a choice
 		 * in practice, so it may not matter.
@@ -2553,12 +2554,13 @@ make_group(PlannerInfo *root,
 	 * We also need to account for the cost of evaluation of the qual (ie, the
 	 * HAVING clause) and the tlist.
 	 *
-	 * XXX this double-counts the cost of evaluation of any expressions used for
-	 * grouping, since in reality those will have been evaluated at a lower
-	 * plan level and will only be copied by the Group node. Worth fixing?
+	 * XXX this double-counts the cost of evaluation of any expressions used
+	 * for grouping, since in reality those will have been evaluated at a
+	 * lower plan level and will only be copied by the Group node. Worth
+	 * fixing?
 	 *
-	 * See notes in grouping_planner about why this routine and make_agg are the
-	 * only ones in this file that worry about tlist eval cost.
+	 * See notes in grouping_planner about why this routine and make_agg are
+	 * the only ones in this file that worry about tlist eval cost.
 	 */
 	if (qual)
 	{
@@ -2715,8 +2717,8 @@ make_limit(Plan *lefttree, Node *limitOffset, Node *limitCount,
 	 * building a subquery then it's important to report correct info to the
 	 * outer planner.
 	 *
-	 * When the offset or count couldn't be estimated, use 10% of the estimated
-	 * number of rows emitted from the subplan.
+	 * When the offset or count couldn't be estimated, use 10% of the
+	 * estimated number of rows emitted from the subplan.
 	 */
 	if (offset_est != 0)
 	{
--- a/src/backend/optimizer/plan/initsplan.c
+++ b/src/backend/optimizer/plan/initsplan.c
@@ -8,7 +8,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/plan/initsplan.c,v 1.110.2.1 2005/11/14 23:54:35 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/plan/initsplan.c,v 1.110.2.2 2005/11/22 18:23:11 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -466,8 +466,8 @@ distribute_qual_to_rels(PlannerInfo *root, Node *clause,
 		 * we'd produce no output rows, rather than the intended single
 		 * null-extended row, for any nonnullable-side rows failing the qual.
 		 *
-		 * Note: an outer-join qual that mentions only nullable-side rels can be
-		 * pushed down into the nullable side without changing the join
+		 * Note: an outer-join qual that mentions only nullable-side rels can
+		 * be pushed down into the nullable side without changing the join
 		 * result, so we treat it the same as an ordinary inner-join qual,
 		 * except for not setting maybe_equijoin (see below).
 		 */
@@ -860,8 +860,8 @@ process_implied_equality(PlannerInfo *root,
 	/*
 	 * Push the new clause into all the appropriate restrictinfo lists.
 	 *
-	 * Note: we mark the qual "pushed down" to ensure that it can never be taken
-	 * for an original JOIN/ON clause.
+	 * Note: we mark the qual "pushed down" to ensure that it can never be
+	 * taken for an original JOIN/ON clause.
 	 */
 	distribute_qual_to_rels(root, (Node *) clause,
 							true, true, false, NULL, relids);
--- a/src/backend/optimizer/plan/planagg.c
+++ b/src/backend/optimizer/plan/planagg.c
@@ -8,7 +8,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/plan/planagg.c,v 1.10 2005/10/15 02:49:20 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/plan/planagg.c,v 1.10.2.1 2005/11/22 18:23:11 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -93,9 +93,9 @@ optimize_minmax_aggregates(PlannerInfo *root, List *tlist, Path *best_path)
 	/*
 	 * Reject unoptimizable cases.
 	 *
-	 * We don't handle GROUP BY, because our current implementations of grouping
-	 * require looking at all the rows anyway, and so there's not much point
-	 * in optimizing MIN/MAX.
+	 * We don't handle GROUP BY, because our current implementations of
+	 * grouping require looking at all the rows anyway, and so there's not
+	 * much point in optimizing MIN/MAX.
 	 */
 	if (parse->groupClause)
 		return NULL;
@@ -160,9 +160,9 @@ optimize_minmax_aggregates(PlannerInfo *root, List *tlist, Path *best_path)
 	/*
 	 * Make the cost comparison.
 	 *
-	 * Note that we don't include evaluation cost of the tlist here; this is OK
-	 * since it isn't included in best_path's cost either, and should be the
-	 * same in either case.
+	 * Note that we don't include evaluation cost of the tlist here; this is
+	 * OK since it isn't included in best_path's cost either, and should be
+	 * the same in either case.
 	 */
 	cost_agg(&agg_p, root, AGG_PLAIN, list_length(aggs_list),
 			 0, 0,
@@ -493,12 +493,12 @@ make_agg_subplan(PlannerInfo *root, MinMaxAggInfo *info, List *constant_quals)
 	 * node above it.  We might need a gating Result, too, to handle any
 	 * non-variable qual clauses.
 	 *
-	 * Also we must add a "WHERE foo IS NOT NULL" restriction to the indexscan,
-	 * to be sure we don't return a NULL, which'd be contrary to the standard
-	 * behavior of MIN/MAX.  XXX ideally this should be done earlier, so that
-	 * the selectivity of the restriction could be included in our cost
-	 * estimates.  But that looks painful, and in most cases the fraction of
-	 * NULLs isn't high enough to change the decision.
+	 * Also we must add a "WHERE foo IS NOT NULL" restriction to the
+	 * indexscan, to be sure we don't return a NULL, which'd be contrary to
+	 * the standard behavior of MIN/MAX.  XXX ideally this should be done
+	 * earlier, so that the selectivity of the restriction could be included
+	 * in our cost estimates.  But that looks painful, and in most cases the
+	 * fraction of NULLs isn't high enough to change the decision.
 	 */
 	plan = create_plan(&subroot, (Path *) info->path);

--- a/src/backend/optimizer/plan/planmain.c
+++ b/src/backend/optimizer/plan/planmain.c
@@ -14,7 +14,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/plan/planmain.c,v 1.89 2005/10/15 02:49:20 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/plan/planmain.c,v 1.89.2.1 2005/11/22 18:23:11 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -146,11 +146,11 @@ query_planner(PlannerInfo *root, List *tlist, double tuple_fraction,
 	 * added to appropriate lists belonging to the mentioned relations.  We
 	 * also build lists of equijoined keys for pathkey construction.
 	 *
-	 * Note: all subplan nodes will have "flat" (var-only) tlists. This implies
-	 * that all expression evaluations are done at the root of the plan tree.
-	 * Once upon a time there was code to try to push expensive function calls
-	 * down to lower plan nodes, but that's dead code and has been for a long
-	 * time...
+	 * Note: all subplan nodes will have "flat" (var-only) tlists. This
+	 * implies that all expression evaluations are done at the root of the
+	 * plan tree. Once upon a time there was code to try to push expensive
+	 * function calls down to lower plan nodes, but that's dead code and has
+	 * been for a long time...
 	 */
 	build_base_rel_tlists(root, tlist);

@@ -273,9 +273,9 @@ query_planner(PlannerInfo *root, List *tlist, double tuple_fraction,
 	 * "cheapest presorted" path will be the cheapest overall for the tuple
 	 * fraction.)
 	 *
-	 * The cheapest-total path is also the one to use if grouping_planner decides
-	 * to use hashed aggregation, so we return it separately even if this
-	 * routine thinks the presorted path is the winner.
+	 * The cheapest-total path is also the one to use if grouping_planner
+	 * decides to use hashed aggregation, so we return it separately even if
+	 * this routine thinks the presorted path is the winner.
 	 */
 	cheapestpath = final_rel->cheapest_total_path;

--- a/src/backend/optimizer/plan/planner.c
+++ b/src/backend/optimizer/plan/planner.c
@@ -8,7 +8,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.194 2005/10/15 02:49:20 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/plan/planner.c,v 1.194.2.1 2005/11/22 18:23:11 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -99,9 +99,9 @@ planner(Query *parse, bool isCursor, int cursorOptions,
 	 * multiple sub-queries. Also, boundParams is explicitly info from outside
 	 * the query, and so is likewise better handled as a global variable.
 	 *
-	 * Note we do NOT save and restore PlannerPlanId: it exists to assign unique
-	 * IDs to SubPlan nodes, and we want those IDs to be unique for the life
-	 * of a backend.  Also, PlannerInitPlan is saved/restored in
+	 * Note we do NOT save and restore PlannerPlanId: it exists to assign
+	 * unique IDs to SubPlan nodes, and we want those IDs to be unique for the
+	 * life of a backend.  Also, PlannerInitPlan is saved/restored in
 	 * subquery_planner, not here.
 	 */
 	save_PlannerQueryLevel = PlannerQueryLevel;
@@ -302,14 +302,14 @@ subquery_planner(Query *parse, double tuple_fraction,
 	 * HAVING clause into WHERE, in hopes of eliminating tuples before
 	 * aggregation instead of after.
 	 *
-	 * If the query has explicit grouping then we can simply move such a clause
-	 * into WHERE; any group that fails the clause will not be in the output
-	 * because none of its tuples will reach the grouping or aggregation
-	 * stage.  Otherwise we must have a degenerate (variable-free) HAVING
-	 * clause, which we put in WHERE so that query_planner() can use it in a
-	 * gating Result node, but also keep in HAVING to ensure that we don't
-	 * emit a bogus aggregated row. (This could be done better, but it seems
-	 * not worth optimizing.)
+	 * If the query has explicit grouping then we can simply move such a
+	 * clause into WHERE; any group that fails the clause will not be in the
+	 * output because none of its tuples will reach the grouping or
+	 * aggregation stage.  Otherwise we must have a degenerate (variable-free)
+	 * HAVING clause, which we put in WHERE so that query_planner() can use it
+	 * in a gating Result node, but also keep in HAVING to ensure that we
+	 * don't emit a bogus aggregated row. (This could be done better, but it
+	 * seems not worth optimizing.)
 	 *
 	 * Note that both havingQual and parse->jointree->quals are in
 	 * implicitly-ANDed-list form at this point, even though they are declared
@@ -426,8 +426,8 @@ preprocess_expression(PlannerInfo *root, Node *expr, int kind)
 	 * careful to maintain AND/OR flatness --- that is, do not generate a tree
 	 * with AND directly under AND, nor OR directly under OR.
 	 *
-	 * Because this is a relatively expensive process, we skip it when the query
-	 * is trivial, such as "SELECT 2+2;" or "INSERT ... VALUES()". The
+	 * Because this is a relatively expensive process, we skip it when the
+	 * query is trivial, such as "SELECT 2+2;" or "INSERT ... VALUES()". The
 	 * expression will only be evaluated once anyway, so no point in
 	 * pre-simplifying; we can't execute it any faster than the executor can,
 	 * and we will waste cycles copying the tree.  Notice however that we
@@ -577,13 +577,13 @@ inheritance_planner(PlannerInfo *root, List *inheritlist)
 		 * XXX my goodness this next bit is ugly.  Really need to think about
 		 * ways to rein in planner's habit of scribbling on its input.
 		 *
-		 * Planning of the subquery might have modified the rangetable, either by
-		 * addition of RTEs due to expansion of inherited source tables, or by
-		 * changes of the Query structures inside subquery RTEs.  We have to
-		 * ensure that this gets propagated back to the master copy.  However,
-		 * if we aren't done planning yet, we also need to ensure that
-		 * subsequent calls to grouping_planner have virgin sub-Queries to
-		 * work from.  So, if we are at the last list entry, just copy the
+		 * Planning of the subquery might have modified the rangetable, either
+		 * by addition of RTEs due to expansion of inherited source tables, or
+		 * by changes of the Query structures inside subquery RTEs.  We have
+		 * to ensure that this gets propagated back to the master copy.
+		 * However, if we aren't done planning yet, we also need to ensure
+		 * that subsequent calls to grouping_planner have virgin sub-Queries
+		 * to work from.  So, if we are at the last list entry, just copy the
 		 * subquery rangetable back to the master copy; if we are not, then
 		 * extend the master copy by adding whatever the subquery added.  (We
 		 * assume these added entries will go untouched by the future
@@ -759,8 +759,8 @@ grouping_planner(PlannerInfo *root, double tuple_fraction)
 		 * Note: we do not attempt to detect duplicate aggregates here; a
 		 * somewhat-overestimated count is okay for our present purposes.
 		 *
-		 * Note: think not that we can turn off hasAggs if we find no aggs. It is
-		 * possible for constant-expression simplification to remove all
+		 * Note: think not that we can turn off hasAggs if we find no aggs. It
+		 * is possible for constant-expression simplification to remove all
 		 * explicit references to aggs, but we still have to follow the
 		 * aggregate semantics (eg, producing only one output row).
 		 */
@@ -980,8 +980,8 @@ grouping_planner(PlannerInfo *root, double tuple_fraction)
 				 * GROUP BY without aggregation, so insert a group node (plus
 				 * the appropriate sort node, if necessary).
 				 *
-				 * Add an explicit sort if we couldn't make the path come out the
-				 * way the GROUP node needs it.
+				 * Add an explicit sort if we couldn't make the path come out
+				 * the way the GROUP node needs it.
 				 */
 				if (!pathkeys_contained_in(group_pathkeys, current_pathkeys))
 				{
@@ -1329,14 +1329,15 @@ choose_hashed_grouping(PlannerInfo *root, double tuple_fraction,
 	 * output won't be sorted may be a loss; so we need to do an actual cost
 	 * comparison.
 	 *
-	 * We need to consider cheapest_path + hashagg [+ final sort] versus either
-	 * cheapest_path [+ sort] + group or agg [+ final sort] or presorted_path
-	 * + group or agg [+ final sort] where brackets indicate a step that may
-	 * not be needed. We assume query_planner() will have returned a presorted
-	 * path only if it's a winner compared to cheapest_path for this purpose.
+	 * We need to consider cheapest_path + hashagg [+ final sort] versus
+	 * either cheapest_path [+ sort] + group or agg [+ final sort] or
+	 * presorted_path + group or agg [+ final sort] where brackets indicate a
+	 * step that may not be needed. We assume query_planner() will have
+	 * returned a presorted path only if it's a winner compared to
+	 * cheapest_path for this purpose.
 	 *
-	 * These path variables are dummies that just hold cost fields; we don't make
-	 * actual Paths for these steps.
+	 * These path variables are dummies that just hold cost fields; we don't
+	 * make actual Paths for these steps.
 	 */
 	cost_agg(&hashed_p, root, AGG_HASHED, agg_counts->numAggs,
 			 numGroupCols, dNumGroups,
--- a/src/backend/optimizer/plan/setrefs.c
+++ b/src/backend/optimizer/plan/setrefs.c
@@ -9,7 +9,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/plan/setrefs.c,v 1.117 2005/11/03 17:45:29 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/plan/setrefs.c,v 1.117.2.1 2005/11/22 18:23:11 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -608,8 +608,8 @@ adjust_plan_varnos(Plan *plan, int rtoffset)
 	/*
 	 * Now recurse into child plans.
 	 *
-	 * We don't need to (and in fact mustn't) recurse into subqueries, so no need
-	 * to examine initPlan list.
+	 * We don't need to (and in fact mustn't) recurse into subqueries, so no
+	 * need to examine initPlan list.
 	 */
 	adjust_plan_varnos(plan->lefttree, rtoffset);
 	adjust_plan_varnos(plan->righttree, rtoffset);
@@ -853,8 +853,8 @@ set_inner_join_references(Plan *inner_plan,
 		 * The inner side is a bitmap scan plan.  Fix the top node, and
 		 * recurse to get the lower nodes.
 		 *
-		 * Note: create_bitmap_scan_plan removes clauses from bitmapqualorig if
-		 * they are duplicated in qpqual, so must test these independently.
+		 * Note: create_bitmap_scan_plan removes clauses from bitmapqualorig
+		 * if they are duplicated in qpqual, so must test these independently.
 		 */
 		BitmapHeapScan *innerscan = (BitmapHeapScan *) inner_plan;
 		Index		innerrel = innerscan->scan.scanrelid;
--- a/src/backend/optimizer/plan/subselect.c
+++ b/src/backend/optimizer/plan/subselect.c
@@ -7,7 +7,7 @@
 * Portions Copyright (c) 1994, Regents of the University of California
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/plan/subselect.c,v 1.100 2005/10/15 02:49:20 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/plan/subselect.c,v 1.100.2.1 2005/11/22 18:23:11 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -118,10 +118,10 @@ replace_outer_var(Var *var)
 	 * this sort of aliasing will cause no trouble. The correct field should
 	 * get stored into the Param slot at execution in each part of the tree.
 	 *
-	 * We also need to demand a match on vartypmod.  This does not matter for the
-	 * Param itself, since those are not typmod-dependent, but it does matter
-	 * when make_subplan() instantiates a modified copy of the Var for a
-	 * subplan's args list.
+	 * We also need to demand a match on vartypmod.  This does not matter for
+	 * the Param itself, since those are not typmod-dependent, but it does
+	 * matter when make_subplan() instantiates a modified copy of the Var for
+	 * a subplan's args list.
 	 */
 	i = 0;
 	foreach(ppl, PlannerParamList)
@@ -267,8 +267,8 @@ make_subplan(SubLink *slink, List *lefthand, bool isTopQual)
 	 * 50% retrieval.  For EXPR and MULTIEXPR subplans, use default behavior
 	 * (we're only expecting one row out, anyway).
 	 *
-	 * NOTE: if you change these numbers, also change cost_qual_eval_walker() in
-	 * path/costsize.c.
+	 * NOTE: if you change these numbers, also change cost_qual_eval_walker()
+	 * in path/costsize.c.
 	 *
 	 * XXX If an ALL/ANY subplan is uncorrelated, we may decide to hash or
 	 * materialize its result below.  In that case it would've been better to
@@ -698,10 +698,10 @@ convert_IN_to_join(PlannerInfo *root, SubLink *sublink)
 	/*
 	 * Okay, pull up the sub-select into top range table and jointree.
 	 *
-	 * We rely here on the assumption that the outer query has no references to
-	 * the inner (necessarily true, other than the Vars that we build below).
-	 * Therefore this is a lot easier than what pull_up_subqueries has to go
-	 * through.
+	 * We rely here on the assumption that the outer query has no references
+	 * to the inner (necessarily true, other than the Vars that we build
+	 * below). Therefore this is a lot easier than what pull_up_subqueries has
+	 * to go through.
 	 */
 	rte = addRangeTableEntryForSubquery(NULL,
 										subselect,
@@ -938,9 +938,9 @@ SS_finalize_plan(Plan *plan, List *rtable)
 	 * Finally, attach any initPlans to the topmost plan node, and add their
 	 * extParams to the topmost node's, too.
 	 *
-	 * We also add the total_cost of each initPlan to the startup cost of the top
-	 * node.  This is a conservative overestimate, since in fact each initPlan
-	 * might be executed later than plan startup, or even not at all.
+	 * We also add the total_cost of each initPlan to the startup cost of the
+	 * top node.  This is a conservative overestimate, since in fact each
+	 * initPlan might be executed later than plan startup, or even not at all.
 	 */
 	plan->initPlan = PlannerInitPlan;
 	PlannerInitPlan = NIL;		/* make sure they're not attached twice */
--- a/src/backend/optimizer/prep/prepjointree.c
+++ b/src/backend/optimizer/prep/prepjointree.c
@@ -16,7 +16,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/prep/prepjointree.c,v 1.31 2005/10/15 02:49:20 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/prep/prepjointree.c,v 1.31.2.1 2005/11/22 18:23:11 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -198,9 +198,9 @@ pull_up_subqueries(PlannerInfo *root, Node *jtnode, bool below_outer_join)
 			 * routine's processing is complete for its jointree and
 			 * rangetable.
 			 *
-			 * Note: 'false' is correct here even if we are within an outer join
-			 * in the upper query; the lower query starts with a clean slate
-			 * for outer-join semantics.
+			 * Note: 'false' is correct here even if we are within an outer
+			 * join in the upper query; the lower query starts with a clean
+			 * slate for outer-join semantics.
 			 */
 			subquery->jointree = (FromExpr *)
 				pull_up_subqueries(subroot, (Node *) subquery->jointree,
@@ -210,9 +210,9 @@ pull_up_subqueries(PlannerInfo *root, Node *jtnode, bool below_outer_join)
 			 * Now we must recheck whether the subquery is still simple enough
 			 * to pull up.	If not, abandon processing it.
 			 *
-			 * We don't really need to recheck all the conditions involved, but
-			 * it's easier just to keep this "if" looking the same as the one
-			 * above.
+			 * We don't really need to recheck all the conditions involved,
+			 * but it's easier just to keep this "if" looking the same as the
+			 * one above.
 			 */
 			if (is_simple_subquery(subquery) &&
 				(!below_outer_join || has_nullable_targetlist(subquery)))
@@ -294,8 +294,8 @@ pull_up_subqueries(PlannerInfo *root, Node *jtnode, bool below_outer_join)
 			 * already adjusted the marker values, so just list_concat the
 			 * list.)
 			 *
-			 * Executor can't handle multiple FOR UPDATE/SHARE/NOWAIT flags, so
-			 * complain if they are valid but different
+			 * Executor can't handle multiple FOR UPDATE/SHARE/NOWAIT flags,
+			 * so complain if they are valid but different
 			 */
 			if (parse->rowMarks && subquery->rowMarks)
 			{
--- a/src/backend/optimizer/prep/prepqual.c
+++ b/src/backend/optimizer/prep/prepqual.c
@@ -25,7 +25,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/prep/prepqual.c,v 1.51 2005/10/15 02:49:21 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/prep/prepqual.c,v 1.51.2.1 2005/11/22 18:23:11 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -431,9 +431,9 @@ process_duplicate_ors(List *orlist)
 	/*
 	 * Generate new OR list consisting of the remaining sub-clauses.
 	 *
-	 * If any clause degenerates to empty, then we have a situation like (A AND
-	 * B) OR (A), which can be reduced to just A --- that is, the additional
-	 * conditions in other arms of the OR are irrelevant.
+	 * If any clause degenerates to empty, then we have a situation like (A
+	 * AND B) OR (A), which can be reduced to just A --- that is, the
+	 * additional conditions in other arms of the OR are irrelevant.
 	 *
 	 * Note that because we use list_difference, any multiple occurrences of a
 	 * winning clause in an AND sub-clause will be removed automatically.
--- a/src/backend/optimizer/prep/preptlist.c
+++ b/src/backend/optimizer/prep/preptlist.c
@@ -15,7 +15,7 @@
 * Portions Copyright (c) 1994, Regents of the University of California
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/prep/preptlist.c,v 1.78 2005/10/15 02:49:21 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/prep/preptlist.c,v 1.78.2.1 2005/11/22 18:23:11 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -64,8 +64,8 @@ preprocess_targetlist(PlannerInfo *root, List *tlist)

 	/*
 	 * for heap_formtuple to work, the targetlist must match the exact order
-	 * of the attributes. We also need to fill in any missing attributes.
-	 * -ay 10/94
+	 * of the attributes. We also need to fill in any missing attributes. -ay
+	 * 10/94
 	 */
 	if (command_type == CMD_INSERT || command_type == CMD_UPDATE)
 		tlist = expand_targetlist(tlist, command_type,
@@ -185,10 +185,10 @@ expand_targetlist(List *tlist, int command_type,
 	 * The rewriter should have already ensured that the TLEs are in correct
 	 * order; but we have to insert TLEs for any missing attributes.
 	 *
-	 * Scan the tuple description in the relation's relcache entry to make sure
-	 * we have all the user attributes in the right order.	We assume that the
-	 * rewriter already acquired at least AccessShareLock on the relation, so
-	 * we need no lock here.
+	 * Scan the tuple description in the relation's relcache entry to make
+	 * sure we have all the user attributes in the right order.  We assume
+	 * that the rewriter already acquired at least AccessShareLock on the
+	 * relation, so we need no lock here.
 	 */
 	rel = heap_open(getrelid(result_relation, range_table), NoLock);

@@ -220,18 +220,19 @@ expand_targetlist(List *tlist, int command_type,
 			 * column isn't dropped, apply any domain constraints that might
 			 * exist --- this is to catch domain NOT NULL.
 			 *
-			 * For UPDATE, generate a Var reference to the existing value of the
-			 * attribute, so that it gets copied to the new tuple. But
+			 * For UPDATE, generate a Var reference to the existing value of
+			 * the attribute, so that it gets copied to the new tuple. But
 			 * generate a NULL for dropped columns (we want to drop any old
 			 * values).
 			 *
-			 * When generating a NULL constant for a dropped column, we label it
-			 * INT4 (any other guaranteed-to-exist datatype would do as well).
-			 * We can't label it with the dropped column's datatype since that
-			 * might not exist anymore.  It does not really matter what we
-			 * claim the type is, since NULL is NULL --- its representation is
-			 * datatype-independent.  This could perhaps confuse code
-			 * comparing the finished plan to the target relation, however.
+			 * When generating a NULL constant for a dropped column, we label
+			 * it INT4 (any other guaranteed-to-exist datatype would do as
+			 * well). We can't label it with the dropped column's datatype
+			 * since that might not exist anymore.	It does not really matter
+			 * what we claim the type is, since NULL is NULL --- its
+			 * representation is datatype-independent.	This could perhaps
+			 * confuse code comparing the finished plan to the target
+			 * relation, however.
 			 */
 			Oid			atttype = att_tup->atttypid;
 			int32		atttypmod = att_tup->atttypmod;
--- a/src/backend/optimizer/prep/prepunion.c
+++ b/src/backend/optimizer/prep/prepunion.c
@@ -14,7 +14,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/prep/prepunion.c,v 1.127 2005/10/15 02:49:21 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/prep/prepunion.c,v 1.127.2.1 2005/11/22 18:23:11 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -439,8 +439,8 @@ recurse_union_children(Node *setOp, PlannerInfo *root,
 	/*
 	 * Not same, so plan this child separately.
 	 *
-	 * Note we disallow any resjunk columns in child results.  This is necessary
-	 * since the Append node that implements the union won't do any
+	 * Note we disallow any resjunk columns in child results.  This is
+	 * necessary since the Append node that implements the union won't do any
 	 * projection, and upper levels will get confused if some of our output
 	 * tuples have junk and some don't.  This case only arises when we have an
 	 * EXCEPT or INTERSECT as child, else there won't be resjunk anyway.
@@ -495,9 +495,9 @@ generate_setop_tlist(List *colTypes, int flag,
 		 * data types and column names.  Insert datatype coercions where
 		 * necessary.
 		 *
-		 * HACK: constants in the input's targetlist are copied up as-is rather
-		 * than being referenced as subquery outputs.  This is mainly to
-		 * ensure that when we try to coerce them to the output column's
+		 * HACK: constants in the input's targetlist are copied up as-is
+		 * rather than being referenced as subquery outputs.  This is mainly
+		 * to ensure that when we try to coerce them to the output column's
 		 * datatype, the right things happen for UNKNOWN constants.  But do
 		 * this only at the first level of subquery-scan plans; we don't want
 		 * phony constants appearing in the output tlists of upper-level
--- a/src/backend/optimizer/util/clauses.c
+++ b/src/backend/optimizer/util/clauses.c
@@ -8,7 +8,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/util/clauses.c,v 1.201 2005/10/15 02:49:21 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/util/clauses.c,v 1.201.2.1 2005/11/22 18:23:12 momjian Exp $
 *
 * HISTORY
 *	  AUTHOR			DATE			MAJOR EVENT
@@ -1803,8 +1803,8 @@ eval_const_expressions_mutator(Node *node,
 		 * simplifying functions.)	Also, we can optimize field selection from
 		 * a RowExpr construct.
 		 *
-		 * We must however check that the declared type of the field is still the
-		 * same as when the FieldSelect was created --- this can change if
+		 * We must however check that the declared type of the field is still
+		 * the same as when the FieldSelect was created --- this can change if
 		 * someone did ALTER COLUMN TYPE on the rowtype.
 		 */
 		FieldSelect *fselect = (FieldSelect *) node;
@@ -2638,10 +2638,10 @@ evaluate_expr(Expr *expr, Oid result_type)
 	/*
 	 * And evaluate it.
 	 *
-	 * It is OK to use a default econtext because none of the ExecEvalExpr() code
-	 * used in this situation will use econtext.  That might seem fortuitous,
-	 * but it's not so unreasonable --- a constant expression does not depend
-	 * on context, by definition, n'est ce pas?
+	 * It is OK to use a default econtext because none of the ExecEvalExpr()
+	 * code used in this situation will use econtext.  That might seem
+	 * fortuitous, but it's not so unreasonable --- a constant expression does
+	 * not depend on context, by definition, n'est ce pas?
 	 */
 	const_val = ExecEvalExprSwitchContext(exprstate,
 										  GetPerTupleExprContext(estate),
@@ -2774,9 +2774,9 @@ expression_tree_walker(Node *node,
 	 * The walker has already visited the current node, and so we need only
 	 * recurse into any sub-nodes it has.
 	 *
-	 * We assume that the walker is not interested in List nodes per se, so when
-	 * we expect a List we just recurse directly to self without bothering to
-	 * call the walker.
+	 * We assume that the walker is not interested in List nodes per se, so
+	 * when we expect a List we just recurse directly to self without
+	 * bothering to call the walker.
 	 */
 	if (node == NULL)
 		return false;
--- a/src/backend/optimizer/util/plancat.c
+++ b/src/backend/optimizer/util/plancat.c
@@ -9,7 +9,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/util/plancat.c,v 1.114 2005/10/15 02:49:21 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/util/plancat.c,v 1.114.2.1 2005/11/22 18:23:12 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -132,10 +132,10 @@ get_relation_info(Oid relationObjectId, RelOptInfo *rel)
 			/*
 			 * Extract info from the relation descriptor for the index.
 			 *
-			 * Note that we take no lock on the index; we assume our lock on the
-			 * parent table will protect the index's schema information. When
-			 * and if the executor actually uses the index, it will take a
-			 * lock as needed to protect the access to the index contents.
+			 * Note that we take no lock on the index; we assume our lock on
+			 * the parent table will protect the index's schema information.
+			 * When and if the executor actually uses the index, it will take
+			 * a lock as needed to protect the access to the index contents.
 			 */
 			indexRelation = index_open(indexoid);
 			index = indexRelation->rd_index;
@@ -265,11 +265,11 @@ estimate_rel_size(Relation rel, int32 *attr_widths,
 			 * infrastructure for redoing cached plans at all, so we have to
 			 * kluge things here instead.
 			 *
-			 * We approximate "never vacuumed" by "has relpages = 0", which means
-			 * this will also fire on genuinely empty relations.  Not great,
-			 * but fortunately that's a seldom-seen case in the real world,
-			 * and it shouldn't degrade the quality of the plan too much
-			 * anyway to err in this direction.
+			 * We approximate "never vacuumed" by "has relpages = 0", which
+			 * means this will also fire on genuinely empty relations.	Not
+			 * great, but fortunately that's a seldom-seen case in the real
+			 * world, and it shouldn't degrade the quality of the plan too
+			 * much anyway to err in this direction.
 			 */
 			if (curpages < 10 && rel->rd_rel->relpages == 0)
 				curpages = 10;
--- a/src/backend/optimizer/util/relnode.c
+++ b/src/backend/optimizer/util/relnode.c
@@ -8,7 +8,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/util/relnode.c,v 1.72 2005/10/15 02:49:21 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/util/relnode.c,v 1.72.2.1 2005/11/22 18:23:12 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -263,9 +263,9 @@ find_join_rel(PlannerInfo *root, Relids relids)
 	/*
 	 * Use either hashtable lookup or linear search, as appropriate.
 	 *
-	 * Note: the seemingly redundant hashkey variable is used to avoid taking the
-	 * address of relids; unless the compiler is exceedingly smart, doing so
-	 * would force relids out of a register and thus probably slow down the
+	 * Note: the seemingly redundant hashkey variable is used to avoid taking
+	 * the address of relids; unless the compiler is exceedingly smart, doing
+	 * so would force relids out of a register and thus probably slow down the
 	 * list-search case.
 	 */
 	if (root->join_rel_hash)
@@ -533,8 +533,8 @@ build_joinrel_restrictlist(PlannerInfo *root,
 	/*
 	 * Eliminate duplicate and redundant clauses.
 	 *
-	 * We must eliminate duplicates, since we will see many of the same clauses
-	 * arriving from both input relations.	Also, if a clause is a
+	 * We must eliminate duplicates, since we will see many of the same
+	 * clauses arriving from both input relations.	Also, if a clause is a
 	 * mergejoinable clause, it's possible that it is redundant with previous
 	 * clauses (see optimizer/README for discussion).  We detect that case and
 	 * omit the redundant clause from the result list.
--- a/src/backend/optimizer/util/restrictinfo.c
+++ b/src/backend/optimizer/util/restrictinfo.c
@@ -8,7 +8,7 @@
 *
 *
 * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/optimizer/util/restrictinfo.c,v 1.41.2.2 2005/11/16 17:08:12 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/optimizer/util/restrictinfo.c,v 1.41.2.3 2005/11/22 18:23:12 momjian Exp $
 *
 *-------------------------------------------------------------------------
 */
@@ -43,7 +43,7 @@ static RestrictInfo *join_clause_is_redundant(PlannerInfo *root,
 * Build a RestrictInfo node containing the given subexpression.
 *
 * The is_pushed_down and outerjoin_delayed flags must be supplied by the
- * caller.  required_relids can be NULL, in which case it defaults to the
+ * caller.	required_relids can be NULL, in which case it defaults to the
 * actual clause contents (i.e., clause_relids).
 *
 * We initialize fields that depend only on the given subexpression, leaving