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.

src/backend/parser/analyze.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/parser/analyze.c,v 1.326 2005/10/15 02:49:21 momjian Exp $
+ *	$PostgreSQL: pgsql/src/backend/parser/analyze.c,v 1.327 2005/11/22 18:17:15 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -1108,8 +1108,8 @@ transformInhRelation(ParseState *pstate, CreateStmtContext *cxt,
 		/*
 		 * Create a new inherited column.
 		 *
-		 * For constraints, ONLY the NOT NULL constraint is inherited by the new
-		 * column definition per SQL99.
+		 * For constraints, ONLY the NOT NULL constraint is inherited by the
+		 * new column definition per SQL99.
 		 */
 		def = makeNode(ColumnDef);
 		def->colname = pstrdup(attributeName);
@@ -1353,8 +1353,8 @@ transformIndexConstraints(ParseState *pstate, CreateStmtContext *cxt)
 	 * strict reading of SQL92 would suggest raising an error instead, but
 	 * that strikes me as too anal-retentive. - tgl 2001-02-14
 	 *
-	 * XXX in ALTER TABLE case, it'd be nice to look for duplicate pre-existing
-	 * indexes, too.
+	 * XXX in ALTER TABLE case, it'd be nice to look for duplicate
+	 * pre-existing indexes, too.
 	 */
 	cxt->alist = NIL;
 	if (cxt->pkey != NULL)
@@ -1744,8 +1744,8 @@ transformRuleStmt(ParseState *pstate, RuleStmt *stmt,
 			 * For efficiency's sake, add OLD to the rule action's jointree
 			 * only if it was actually referenced in the statement or qual.
 			 *
-			 * For INSERT, NEW is not really a relation (only a reference to the
-			 * to-be-inserted tuple) and should never be added to the
+			 * For INSERT, NEW is not really a relation (only a reference to
+			 * the to-be-inserted tuple) and should never be added to the
 			 * jointree.
 			 *
 			 * For UPDATE, we treat NEW as being another kind of reference to
@@ -1967,10 +1967,10 @@ transformSetOperationStmt(ParseState *pstate, SelectStmt *stmt)
 	 * make lists of the dummy vars and their names for use in parsing ORDER
 	 * BY.
 	 *
-	 * Note: we use leftmostRTI as the varno of the dummy variables. It shouldn't
-	 * matter too much which RT index they have, as long as they have one that
-	 * corresponds to a real RT entry; else funny things may happen when the
-	 * tree is mashed by rule rewriting.
+	 * Note: we use leftmostRTI as the varno of the dummy variables. It
+	 * shouldn't matter too much which RT index they have, as long as they
+	 * have one that corresponds to a real RT entry; else funny things may
+	 * happen when the tree is mashed by rule rewriting.
 	 */
 	qry->targetList = NIL;
 	targetvars = NIL;
@@ -2005,9 +2005,9 @@ transformSetOperationStmt(ParseState *pstate, SelectStmt *stmt)
 	/*
 	 * Handle SELECT INTO/CREATE TABLE AS.
 	 *
-	 * Any column names from CREATE TABLE AS need to be attached to both the top
-	 * level and the leftmost subquery.  We do not do this earlier because we
-	 * do *not* want the targetnames list to be affected.
+	 * Any column names from CREATE TABLE AS need to be attached to both the
+	 * top level and the leftmost subquery.  We do not do this earlier because
+	 * we do *not* want the targetnames list to be affected.
 	 */
 	qry->into = into;
 	if (intoColNames)
@@ -2022,9 +2022,9 @@ transformSetOperationStmt(ParseState *pstate, SelectStmt *stmt)
 	 * output columns visible.	A Join RTE node is handy for this, since we
 	 * can easily control the Vars generated upon matches.
 	 *
-	 * Note: we don't yet do anything useful with such cases, but at least "ORDER
-	 * BY upper(foo)" will draw the right error message rather than "foo not
-	 * found".
+	 * Note: we don't yet do anything useful with such cases, but at least
+	 * "ORDER BY upper(foo)" will draw the right error message rather than
+	 * "foo not found".
 	 */
 	jrte = addRangeTableEntryForJoin(NULL,
 									 targetnames,
@@ -2140,8 +2140,8 @@ transformSetOperationTree(ParseState *pstate, SelectStmt *stmt)
 		/*
 		 * Transform SelectStmt into a Query.
 		 *
-		 * Note: previously transformed sub-queries don't affect the parsing of
-		 * this sub-query, because they are not in the toplevel pstate's
+		 * Note: previously transformed sub-queries don't affect the parsing
+		 * of this sub-query, because they are not in the toplevel pstate's
 		 * namespace list.
 		 */
 		selectList = parse_sub_analyze((Node *) stmt, pstate);

src/backend/parser/keywords.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/parser/keywords.c,v 1.168 2005/11/21 12:49:32 alvherre Exp $
+ *	  $PostgreSQL: pgsql/src/backend/parser/keywords.c,v 1.169 2005/11/22 18:17:15 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -160,7 +160,7 @@ static const ScanKeyword ScanKeywords[] = {
 	{"header", HEADER},
 	{"hold", HOLD},
 	{"hour", HOUR_P},
-	{"if",IF_P},
+	{"if", IF_P},
 	{"ilike", ILIKE},
 	{"immediate", IMMEDIATE},
 	{"immutable", IMMUTABLE},

src/backend/parser/parse_clause.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/parser/parse_clause.c,v 1.143 2005/10/15 02:49:22 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/parser/parse_clause.c,v 1.144 2005/11/22 18:17:16 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -172,9 +172,9 @@ setTargetTable(ParseState *pstate, RangeVar *relation,
 	 * instead mark target table as requiring exactly the specified
 	 * permissions.
 	 *
-	 * If we find an explicit reference to the rel later during parse analysis,
-	 * scanRTEForColumn will add the ACL_SELECT bit back again. That can't
-	 * happen for INSERT but it is possible for UPDATE and DELETE.
+	 * If we find an explicit reference to the rel later during parse
+	 * analysis, scanRTEForColumn will add the ACL_SELECT bit back again. That
+	 * can't happen for INSERT but it is possible for UPDATE and DELETE.
 	 */
 	rte->requiredPerms = requiredPerms;
 
@@ -462,8 +462,8 @@ transformRangeSubselect(ParseState *pstate, RangeSubselect *r)
 	 * XXX this will need further work to support SQL99's LATERAL() feature,
 	 * wherein such references would indeed be legal.
 	 *
-	 * We can skip groveling through the subquery if there's not anything visible
-	 * in the current query.  Also note that outer references are OK.
+	 * We can skip groveling through the subquery if there's not anything
+	 * visible in the current query.  Also note that outer references are OK.
 	 */
 	if (pstate->p_relnamespace || pstate->p_varnamespace)
 	{
@@ -1193,8 +1193,8 @@ findTargetlistEntry(ParseState *pstate, Node *node, List **tlist, int clause)
 			 * than one column name exposed by FROM, colNameToVar will
 			 * ereport(ERROR).	That's just what we want here.
 			 *
-			 * Small tweak for 7.4.3: ignore matches in upper query levels. This
-			 * effectively changes the search order for bare names to (1)
+			 * Small tweak for 7.4.3: ignore matches in upper query levels.
+			 * This effectively changes the search order for bare names to (1)
 			 * local FROM variables, (2) local targetlist aliases, (3) outer
 			 * FROM variables, whereas before it was (1) (3) (2). SQL92 and
 			 * SQL99 do not allow GROUPing BY an outer reference, so this
@@ -1474,9 +1474,9 @@ transformDistinctClause(ParseState *pstate, List *distinctlist,
 		 * DISTINCT values to the sort list, much as we did above for ordinary
 		 * DISTINCT fields.
 		 *
-		 * Actually, it'd be OK for the common prefixes of the two lists to match
-		 * in any order, but implementing that check seems like more trouble
-		 * than it's worth.
+		 * Actually, it'd be OK for the common prefixes of the two lists to
+		 * match in any order, but implementing that check seems like more
+		 * trouble than it's worth.
 		 */
 		ListCell   *nextsortlist = list_head(*sortClause);
 

src/backend/parser/parse_coerce.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/parser/parse_coerce.c,v 2.132 2005/10/15 02:49:22 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/parser/parse_coerce.c,v 2.133 2005/11/22 18:17:16 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -180,9 +180,9 @@ coerce_type(ParseState *pstate, Node *node,
 			 * length checks, which is not always what we want here. Any
 			 * length constraint will be applied later by our caller.
 			 *
-			 * Note that we call stringTypeDatum using the domain's pg_type row,
-			 * if it's a domain.  This works because the domain row has the
-			 * same typinput and typelem as the base type --- ugly...
+			 * Note that we call stringTypeDatum using the domain's pg_type
+			 * row, if it's a domain.  This works because the domain row has
+			 * the same typinput and typelem as the base type --- ugly...
 			 */
 			newcon->constvalue = stringTypeDatum(targetType, val, -1);
 		}
@@ -1670,12 +1670,12 @@ find_coercion_pathway(Oid targetTypeId, Oid sourceTypeId,
 		 * array types.  If so, and if the element types have a suitable cast,
 		 * use array_type_coerce() or array_type_length_coerce().
 		 *
-		 * Hack: disallow coercions to oidvector and int2vector, which otherwise
-		 * tend to capture coercions that should go to "real" array types.	We
-		 * want those types to be considered "real" arrays for many purposes,
-		 * but not this one.  (Also, array_type_coerce isn't guaranteed to
-		 * produce an output that meets the restrictions of these datatypes,
-		 * such as being 1-dimensional.)
+		 * Hack: disallow coercions to oidvector and int2vector, which
+		 * otherwise tend to capture coercions that should go to "real" array
+		 * types.  We want those types to be considered "real" arrays for many
+		 * purposes, but not this one.	(Also, array_type_coerce isn't
+		 * guaranteed to produce an output that meets the restrictions of
+		 * these datatypes, such as being 1-dimensional.)
 		 */
 		Oid			targetElemType;
 		Oid			sourceElemType;

src/backend/parser/parse_expr.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/parser/parse_expr.c,v 1.186 2005/11/18 23:08:00 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/parser/parse_expr.c,v 1.187 2005/11/22 18:17:16 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -365,10 +365,10 @@ transformColumnRef(ParseState *pstate, ColumnRef *cref)
 					/*
 					 * Not known as a column of any range-table entry.
 					 *
-					 * Consider the possibility that it's VALUE in a domain check
-					 * expression.	(We handle VALUE as a name, not a keyword,
-					 * to avoid breaking a lot of applications that have used
-					 * VALUE as a column name in the past.)
+					 * Consider the possibility that it's VALUE in a domain
+					 * check expression.  (We handle VALUE as a name, not a
+					 * keyword, to avoid breaking a lot of applications that
+					 * have used VALUE as a column name in the past.)
 					 */
 					if (pstate->p_value_substitute != NULL &&
 						strcmp(name, "value") == 0)
@@ -781,8 +781,8 @@ transformFuncCall(ParseState *pstate, FuncCall *fn)
 	 * Transform the list of arguments.  We use a shallow list copy and then
 	 * transform-in-place to avoid O(N^2) behavior from repeated lappend's.
 	 *
-	 * XXX: repeated lappend() would no longer result in O(n^2) behavior; worth
-	 * reconsidering this design?
+	 * XXX: repeated lappend() would no longer result in O(n^2) behavior;
+	 * worth reconsidering this design?
 	 */
 	targs = list_copy(fn->args);
 	foreach(args, targs)

src/backend/parser/parse_func.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/parser/parse_func.c,v 1.182 2005/10/15 02:49:22 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/parser/parse_func.c,v 1.183 2005/11/22 18:17:16 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -88,11 +88,11 @@ ParseFuncOrColumn(ParseState *pstate, List *funcname, List *fargs,
 	/*
 	 * Extract arg type info in preparation for function lookup.
 	 *
-	 * If any arguments are Param markers of type VOID, we discard them from the
-	 * parameter list.	This is a hack to allow the JDBC driver to not have to
-	 * distinguish "input" and "output" parameter symbols while parsing
-	 * function-call constructs.  We can't use foreach() because we may modify
-	 * the list ...
+	 * If any arguments are Param markers of type VOID, we discard them from
+	 * the parameter list.	This is a hack to allow the JDBC driver to not
+	 * have to distinguish "input" and "output" parameter symbols while
+	 * parsing function-call constructs.  We can't use foreach() because we
+	 * may modify the list ...
 	 */
 	nargs = 0;
 	for (l = list_head(fargs); l != NULL; l = nextl)
@@ -502,10 +502,10 @@ func_select_candidate(int nargs,
 	/*
 	 * Still too many candidates? Try assigning types for the unknown columns.
 	 *
-	 * NOTE: for a binary operator with one unknown and one non-unknown input, we
-	 * already tried the heuristic of looking for a candidate with the known
-	 * input type on both sides (see binary_oper_exact()). That's essentially
-	 * a special case of the general algorithm we try next.
+	 * NOTE: for a binary operator with one unknown and one non-unknown input,
+	 * we already tried the heuristic of looking for a candidate with the
+	 * known input type on both sides (see binary_oper_exact()). That's
+	 * essentially a special case of the general algorithm we try next.
 	 *
 	 * We do this by examining each unknown argument position to see if we can
 	 * determine a "type category" for it.	If any candidate has an input
@@ -518,10 +518,10 @@ func_select_candidate(int nargs,
 	 * If we are able to determine a type category, also notice whether any of
 	 * the candidates takes a preferred datatype within the category.
 	 *
-	 * Having completed this examination, remove candidates that accept the wrong
-	 * category at any unknown position.  Also, if at least one candidate
-	 * accepted a preferred type at a position, remove candidates that accept
-	 * non-preferred types.
+	 * Having completed this examination, remove candidates that accept the
+	 * wrong category at any unknown position.	Also, if at least one
+	 * candidate accepted a preferred type at a position, remove candidates
+	 * that accept non-preferred types.
 	 *
 	 * If we are down to one candidate at the end, we win.
 	 */
@@ -708,20 +708,20 @@ func_get_detail(List *funcname,
 		 * as "text(name(varchar))" which the code below this point is
 		 * entirely capable of selecting.
 		 *
-		 * "Trivial" coercions are ones that involve binary-compatible types and
-		 * ones that are coercing a previously-unknown-type literal constant
-		 * to a specific type.
+		 * "Trivial" coercions are ones that involve binary-compatible types
+		 * and ones that are coercing a previously-unknown-type literal
+		 * constant to a specific type.
 		 *
 		 * The reason we can restrict our check to binary-compatible coercions
 		 * here is that we expect non-binary-compatible coercions to have an
 		 * implementation function named after the target type. That function
 		 * will be found by normal lookup if appropriate.
 		 *
-		 * NB: it's important that this code stays in sync with what coerce_type
-		 * can do, because the caller will try to apply coerce_type if we
-		 * return FUNCDETAIL_COERCION.	If we return that result for something
-		 * coerce_type can't handle, we'll cause infinite recursion between
-		 * this module and coerce_type!
+		 * NB: it's important that this code stays in sync with what
+		 * coerce_type can do, because the caller will try to apply
+		 * coerce_type if we return FUNCDETAIL_COERCION.  If we return that
+		 * result for something coerce_type can't handle, we'll cause infinite
+		 * recursion between this module and coerce_type!
 		 */
 		if (nargs == 1 && fargs != NIL)
 		{
@@ -983,9 +983,9 @@ ParseComplexProjection(ParseState *pstate, char *funcname, Node *first_arg)
 	/*
 	 * Else do it the hard way with get_expr_result_type().
 	 *
-	 * If it's a Var of type RECORD, we have to work even harder: we have to find
-	 * what the Var refers to, and pass that to get_expr_result_type. That
-	 * task is handled by expandRecordVariable().
+	 * If it's a Var of type RECORD, we have to work even harder: we have to
+	 * find what the Var refers to, and pass that to get_expr_result_type.
+	 * That task is handled by expandRecordVariable().
 	 */
 	if (IsA(first_arg, Var) &&
 		((Var *) first_arg)->vartype == RECORDOID)

src/backend/parser/parse_oper.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/parser/parse_oper.c,v 1.82 2005/10/15 02:49:22 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/parser/parse_oper.c,v 1.83 2005/11/22 18:17:16 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -702,9 +702,9 @@ left_oper(List *op, Oid arg, bool noError)
 		 * First, quickly check to see if there is an exactly matching
 		 * operator (there can be only one such entry in the list).
 		 *
-		 * The returned list has args in the form (0, oprright).  Move the useful
-		 * data into args[0] to keep oper_select_candidate simple. XXX we are
-		 * assuming here that we may scribble on the list!
+		 * The returned list has args in the form (0, oprright).  Move the
+		 * useful data into args[0] to keep oper_select_candidate simple. XXX
+		 * we are assuming here that we may scribble on the list!
 		 */
 		FuncCandidateList clisti;
 

src/backend/parser/parse_relation.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/parser/parse_relation.c,v 1.116 2005/10/26 19:21:54 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/parser/parse_relation.c,v 1.117 2005/11/22 18:17:16 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -301,10 +301,10 @@ scanRTEForColumn(ParseState *pstate, RangeTblEntry *rte, char *colname)
 	 * will be empty strings that cannot match any legal SQL identifier, so we
 	 * don't bother to test for that case here.
 	 *
-	 * Should this somehow go wrong and we try to access a dropped column, we'll
-	 * still catch it by virtue of the checks in get_rte_attribute_type(),
-	 * which is called by make_var().  That routine has to do a cache lookup
-	 * anyway, so the check there is cheap.
+	 * Should this somehow go wrong and we try to access a dropped column,
+	 * we'll still catch it by virtue of the checks in
+	 * get_rte_attribute_type(), which is called by make_var().  That routine
+	 * has to do a cache lookup anyway, so the check there is cheap.
 	 */
 	foreach(c, rte->eref->colnames)
 	{
@@ -1007,9 +1007,9 @@ addImplicitRTE(ParseState *pstate, RangeVar *relation)
 
 	/*
 	 * Note that we set inFromCl true, so that the RTE will be listed
-	 * explicitly if the parsetree is ever decompiled by ruleutils.c.
-	 * This provides a migration path for views/rules that were originally
-	 * written with implicit-RTE syntax.
+	 * explicitly if the parsetree is ever decompiled by ruleutils.c. This
+	 * provides a migration path for views/rules that were originally written
+	 * with implicit-RTE syntax.
 	 */
 	rte = addRangeTableEntry(pstate, relation, NULL, false, true);
 	/* Add to joinlist and relnamespace, but not varnamespace */

src/backend/parser/parse_target.c

@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/parser/parse_target.c,v 1.138 2005/10/15 02:49:22 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/parser/parse_target.c,v 1.139 2005/11/22 18:17:16 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -808,9 +808,9 @@ ExpandIndirectionStar(ParseState *pstate, A_Indirection *ind)
 	 * lookup_rowtype_tupdesc(), which will almost certainly fail as well, but
 	 * it will give an appropriate error message.
 	 *
-	 * If it's a Var of type RECORD, we have to work even harder: we have to find
-	 * what the Var refers to, and pass that to get_expr_result_type. That
-	 * task is handled by expandRecordVariable().
+	 * If it's a Var of type RECORD, we have to work even harder: we have to
+	 * find what the Var refers to, and pass that to get_expr_result_type.
+	 * That task is handled by expandRecordVariable().
 	 */
 	if (IsA(expr, Var) &&
 		((Var *) expr)->vartype == RECORDOID)