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.

4 files changed, 28 insertions, 28 deletions

diff --git a/src/backend/optimizer/util/clauses.c b/src/backend/optimizer/util/clauses.c
index 5e2718dc635..fc8d530b1e8 100644
--- 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;
diff --git a/src/backend/optimizer/util/plancat.c b/src/backend/optimizer/util/plancat.c
index 16868939405..f3d4e75ece6 100644
--- 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;
diff --git a/src/backend/optimizer/util/relnode.c b/src/backend/optimizer/util/relnode.c
index 3ca43759e96..20b656e0b30 100644
--- 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.
diff --git a/src/backend/optimizer/util/restrictinfo.c b/src/backend/optimizer/util/restrictinfo.c
index 475e51bca6f..076bffd6f12 100644
--- 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