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.

1 files changed, 21 insertions, 21 deletions

diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c
index 32c7711664d..04e36b87b08 100644
--- a/src/backend/executor/execMain.c
+++ b/src/backend/executor/execMain.c
@@ -26,7 +26,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/executor/execMain.c,v 1.256.2.3 2005/11/20 18:38:42 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/executor/execMain.c,v 1.256.2.4 2005/11/22 18:23:08 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -376,10 +376,10 @@ ExecCheckRTEPerms(RangeTblEntry *rte)
 	/*
 	 * userid to check as: current user unless we have a setuid indication.
 	 *
-	 * Note: GetUserId() is presently fast enough that there's no harm in calling
-	 * it separately for each RTE.	If that stops being true, we could call it
-	 * once in ExecCheckRTPerms and pass the userid down from there.  But for
-	 * now, no need for the extra clutter.
+	 * Note: GetUserId() is presently fast enough that there's no harm in
+	 * calling it separately for each RTE.	If that stops being true, we could
+	 * call it once in ExecCheckRTPerms and pass the userid down from there.
+	 * But for now, no need for the extra clutter.
 	 */
 	userid = rte->checkAsUser ? rte->checkAsUser : GetUserId();
 
@@ -582,8 +582,8 @@ InitPlan(QueryDesc *queryDesc, bool explainOnly)
 	 * initialize the executor "tuple" table.  We need slots for all the plan
 	 * nodes, plus possibly output slots for the junkfilter(s). At this point
 	 * we aren't sure if we need junkfilters, so just add slots for them
-	 * unconditionally.  Also, if it's not a SELECT, set up a slot for use
-	 * for trigger output tuples.
+	 * unconditionally.  Also, if it's not a SELECT, set up a slot for use for
+	 * trigger output tuples.
 	 */
 	{
 		int			nSlots = ExecCountSlotsNode(plan);
@@ -797,11 +797,11 @@ InitPlan(QueryDesc *queryDesc, bool explainOnly)
 		/*
 		 * We can skip WAL-logging the insertions, unless PITR is in use.
 		 *
-		 * Note that for a non-temp INTO table, this is safe only because we know
-		 * that the catalog changes above will have been WAL-logged, and so
-		 * RecordTransactionCommit will think it needs to WAL-log the eventual
-		 * transaction commit.	Else the commit might be lost, even though all
-		 * the data is safely fsync'd ...
+		 * Note that for a non-temp INTO table, this is safe only because we
+		 * know that the catalog changes above will have been WAL-logged, and
+		 * so RecordTransactionCommit will think it needs to WAL-log the
+		 * eventual transaction commit.  Else the commit might be lost, even
+		 * though all the data is safely fsync'd ...
 		 */
 		estate->es_into_relation_use_wal = XLogArchivingActive();
 	}
@@ -1495,8 +1495,8 @@ ExecDelete(TupleTableSlot *slot,
 	/*
 	 * delete the tuple
 	 *
-	 * Note: if es_crosscheck_snapshot isn't InvalidSnapshot, we check that the
-	 * row to be deleted is visible to that snapshot, and throw a can't-
+	 * Note: if es_crosscheck_snapshot isn't InvalidSnapshot, we check that
+	 * the row to be deleted is visible to that snapshot, and throw a can't-
 	 * serialize error if not.	This is a special-case behavior needed for
 	 * referential integrity updates in serializable transactions.
 	 */
@@ -1549,9 +1549,9 @@ ldelete:;
 	 * Note: Normally one would think that we have to delete index tuples
 	 * associated with the heap tuple now..
 	 *
-	 * ... but in POSTGRES, we have no need to do this because the vacuum daemon
-	 * automatically opens an index scan and deletes index tuples when it
-	 * finds deleted heap tuples. -cim 9/27/89
+	 * ... but in POSTGRES, we have no need to do this because the vacuum
+	 * daemon automatically opens an index scan and deletes index tuples when
+	 * it finds deleted heap tuples. -cim 9/27/89
 	 */
 
 	/* AFTER ROW DELETE Triggers */
@@ -1635,8 +1635,8 @@ ExecUpdate(TupleTableSlot *slot,
 	/*
 	 * Check the constraints of the tuple
 	 *
-	 * If we generate a new candidate tuple after EvalPlanQual testing, we must
-	 * loop back here and recheck constraints.	(We don't need to redo
+	 * If we generate a new candidate tuple after EvalPlanQual testing, we
+	 * must loop back here and recheck constraints.  (We don't need to redo
 	 * triggers, however.  If there are any BEFORE triggers then trigger.c
 	 * will have done heap_lock_tuple to lock the correct tuple, so there's no
 	 * need to do them again.)
@@ -1648,8 +1648,8 @@ lreplace:;
 	/*
 	 * replace the heap tuple
 	 *
-	 * Note: if es_crosscheck_snapshot isn't InvalidSnapshot, we check that the
-	 * row to be updated is visible to that snapshot, and throw a can't-
+	 * Note: if es_crosscheck_snapshot isn't InvalidSnapshot, we check that
+	 * the row to be updated is visible to that snapshot, and throw a can't-
 	 * serialize error if not.	This is a special-case behavior needed for
 	 * referential integrity updates in serializable transactions.
 	 */