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.

3 files changed, 28 insertions, 28 deletions

diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index c6d300fe482..4e9c0ff8bba 100644
--- a/src/backend/access/heap/heapam.c
+++ b/src/backend/access/heap/heapam.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/access/heap/heapam.c,v 1.200.2.1 2005/11/20 18:38:42 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/access/heap/heapam.c,v 1.200.2.2 2005/11/22 18:23:03 momjian Exp $
  *
  *
  * INTERFACE ROUTINES
@@ -1089,7 +1089,7 @@ heap_get_latest_tid(Relation relation,
  * The return value is the OID assigned to the tuple (either here or by the
  * caller), or InvalidOid if no OID.  The header fields of *tup are updated
  * to match the stored tuple; in particular tup->t_self receives the actual
- * TID where the tuple was stored.  But note that any toasting of fields
+ * TID where the tuple was stored.	But note that any toasting of fields
  * within the tuple data is NOT reflected into *tup.
  */
 Oid
@@ -1136,8 +1136,8 @@ heap_insert(Relation relation, HeapTuple tup, CommandId cid,
 	 * If the new tuple is too big for storage or contains already toasted
 	 * out-of-line attributes from some other relation, invoke the toaster.
 	 *
-	 * Note: below this point, heaptup is the data we actually intend to
-	 * store into the relation; tup is the caller's original untoasted data.
+	 * Note: below this point, heaptup is the data we actually intend to store
+	 * into the relation; tup is the caller's original untoasted data.
 	 */
 	if (HeapTupleHasExternal(tup) ||
 		(MAXALIGN(tup->t_len) > TOAST_TUPLE_THRESHOLD))
@@ -1224,8 +1224,8 @@ heap_insert(Relation relation, HeapTuple tup, CommandId cid,
 	/*
 	 * If tuple is cachable, mark it for invalidation from the caches in case
 	 * we abort.  Note it is OK to do this after WriteBuffer releases the
-	 * buffer, because the heaptup data structure is all in local memory,
-	 * not in the shared buffer.
+	 * buffer, because the heaptup data structure is all in local memory, not
+	 * in the shared buffer.
 	 */
 	CacheInvalidateHeapTuple(relation, heaptup);
 
@@ -1333,8 +1333,8 @@ l1:
 		 * heap_lock_tuple).  LockTuple will release us when we are
 		 * next-in-line for the tuple.
 		 *
-		 * If we are forced to "start over" below, we keep the tuple lock; this
-		 * arranges that we stay at the head of the line while rechecking
+		 * If we are forced to "start over" below, we keep the tuple lock;
+		 * this arranges that we stay at the head of the line while rechecking
 		 * tuple state.
 		 */
 		if (!have_tuple_lock)
@@ -1577,7 +1577,7 @@ simple_heap_delete(Relation relation, ItemPointer tid)
  *
  * On success, the header fields of *newtup are updated to match the new
  * stored tuple; in particular, newtup->t_self is set to the TID where the
- * new tuple was inserted.  However, any TOAST changes in the new tuple's
+ * new tuple was inserted.	However, any TOAST changes in the new tuple's
  * data are not reflected into *newtup.
  *
  * In the failure cases, the routine returns the tuple's t_ctid and t_xmax.
@@ -1649,8 +1649,8 @@ l2:
 		 * heap_lock_tuple).  LockTuple will release us when we are
 		 * next-in-line for the tuple.
 		 *
-		 * If we are forced to "start over" below, we keep the tuple lock; this
-		 * arranges that we stay at the head of the line while rechecking
+		 * If we are forced to "start over" below, we keep the tuple lock;
+		 * this arranges that we stay at the head of the line while rechecking
 		 * tuple state.
 		 */
 		if (!have_tuple_lock)
@@ -1782,8 +1782,8 @@ l2:
 	 * show that it's already being updated, else other processes may try to
 	 * update it themselves.
 	 *
-	 * We need to invoke the toaster if there are already any out-of-line toasted
-	 * values present, or if the new tuple is over-threshold.
+	 * We need to invoke the toaster if there are already any out-of-line
+	 * toasted values present, or if the new tuple is over-threshold.
 	 */
 	newtupsize = MAXALIGN(newtup->t_len);
 
@@ -1886,7 +1886,7 @@ l2:
 	/* NO EREPORT(ERROR) from here till changes are logged */
 	START_CRIT_SECTION();
 
-	RelationPutHeapTuple(relation, newbuf, heaptup); /* insert new tuple */
+	RelationPutHeapTuple(relation, newbuf, heaptup);	/* insert new tuple */
 
 	if (!already_marked)
 	{
@@ -2123,8 +2123,8 @@ l3:
 		 * LockTuple will release us when we are next-in-line for the tuple.
 		 * We must do this even if we are share-locking.
 		 *
-		 * If we are forced to "start over" below, we keep the tuple lock; this
-		 * arranges that we stay at the head of the line while rechecking
+		 * If we are forced to "start over" below, we keep the tuple lock;
+		 * this arranges that we stay at the head of the line while rechecking
 		 * tuple state.
 		 */
 		if (!have_tuple_lock)
diff --git a/src/backend/access/heap/hio.c b/src/backend/access/heap/hio.c
index 800ee4a805b..440c94bf56b 100644
--- a/src/backend/access/heap/hio.c
+++ b/src/backend/access/heap/hio.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/access/heap/hio.c,v 1.58 2005/10/15 02:49:08 momjian Exp $
+ *	  $PostgreSQL: pgsql/src/backend/access/heap/hio.c,v 1.58.2.1 2005/11/22 18:23:04 momjian Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -296,11 +296,11 @@ RelationGetBufferForTuple(Relation relation, Size len,
 	/*
 	 * Remember the new page as our target for future insertions.
 	 *
-	 * XXX should we enter the new page into the free space map immediately, or
-	 * just keep it for this backend's exclusive use in the short run (until
-	 * VACUUM sees it)?  Seems to depend on whether you expect the current
-	 * backend to make more insertions or not, which is probably a good bet
-	 * most of the time.  So for now, don't add it to FSM yet.
+	 * XXX should we enter the new page into the free space map immediately,
+	 * or just keep it for this backend's exclusive use in the short run
+	 * (until VACUUM sees it)?	Seems to depend on whether you expect the
+	 * current backend to make more insertions or not, which is probably a
+	 * good bet most of the time.  So for now, don't add it to FSM yet.
 	 */
 	relation->rd_targblock = BufferGetBlockNumber(buffer);
 
diff --git a/src/backend/access/heap/tuptoaster.c b/src/backend/access/heap/tuptoaster.c
index de5396a5150..2292f696512 100644
--- a/src/backend/access/heap/tuptoaster.c
+++ b/src/backend/access/heap/tuptoaster.c
@@ -8,7 +8,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/access/heap/tuptoaster.c,v 1.53.2.1 2005/11/20 18:38:42 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/access/heap/tuptoaster.c,v 1.53.2.2 2005/11/22 18:23:04 momjian Exp $
  *
  *
  * INTERFACE ROUTINES
@@ -1075,8 +1075,8 @@ toast_save_datum(Relation rel, Datum value)
 		 * FormIndexDatum: this relies on the knowledge that the index columns
 		 * are the same as the initial columns of the table.
 		 *
-		 * Note also that there had better not be any user-created index on the
-		 * TOAST table, since we don't bother to update anything else.
+		 * Note also that there had better not be any user-created index on
+		 * the TOAST table, since we don't bother to update anything else.
 		 */
 		index_insert(toastidx, t_values, t_isnull,
 					 &(toasttup->t_self),
@@ -1214,9 +1214,9 @@ toast_fetch_datum(varattrib *attr)
 	/*
 	 * Read the chunks by index
 	 *
-	 * Note that because the index is actually on (valueid, chunkidx) we will see
-	 * the chunks in chunkidx order, even though we didn't explicitly ask for
-	 * it.
+	 * Note that because the index is actually on (valueid, chunkidx) we will
+	 * see the chunks in chunkidx order, even though we didn't explicitly ask
+	 * for it.
 	 */
 	nextidx = 0;