Re-pgindent varlena.c.

Just to make sure previous commit worked ...

src/backend/utils/adt/varlena.c

@@ -1780,8 +1780,8 @@ varstr_sortsupport(SortSupport ssup, Oid collid, bool bpchar)
 	 *
 	 * Most typically, we'll set the comparator to varstrfastcmp_locale, which
 	 * uses strcoll() to perform comparisons and knows about the special
-	 * requirements of BpChar callers.  However, if LC_COLLATE = C, we can make
-	 * things quite a bit faster with varstrfastcmp_c or bpcharfastcmp_c,
+	 * requirements of BpChar callers.  However, if LC_COLLATE = C, we can
+	 * make things quite a bit faster with varstrfastcmp_c or bpcharfastcmp_c,
 	 * both of which use memcmp() rather than strcoll().
 	 *
 	 * There is a further exception on Windows.  When the database encoding is
@@ -1866,6 +1866,7 @@ varstr_sortsupport(SortSupport ssup, Oid collid, bool bpchar)
 #ifdef HAVE_LOCALE_T
 		sss->locale = locale;
 #endif
+
 		/*
 		 * To avoid somehow confusing a strxfrm() blob and an original string,
 		 * constantly keep track of the variety of data that buf1 and buf2
@@ -2002,16 +2003,16 @@ varstrfastcmp_locale(Datum x, Datum y, SortSupport ssup)
 	{
 		/*
 		 * No change in buf1 or buf2 contents, so avoid changing last_len1 or
-		 * last_len2.  Existing contents of buffers might still be used by next
-		 * call.
+		 * last_len2.  Existing contents of buffers might still be used by
+		 * next call.
 		 *
-		 * It's fine to allow the comparison of BpChar padding bytes here, even
-		 * though that implies that the memcmp() will usually be performed for
-		 * BpChar callers (though multibyte characters could still prevent that
-		 * from occurring).  The memcmp() is still very cheap, and BpChar's
-		 * funny semantics have us remove trailing spaces (not limited to
-		 * padding), so we need make no distinction between padding space
-		 * characters and "real" space characters.
+		 * It's fine to allow the comparison of BpChar padding bytes here,
+		 * even though that implies that the memcmp() will usually be
+		 * performed for BpChar callers (though multibyte characters could
+		 * still prevent that from occurring).  The memcmp() is still very
+		 * cheap, and BpChar's funny semantics have us remove trailing spaces
+		 * (not limited to padding), so we need make no distinction between
+		 * padding space characters and "real" space characters.
 		 */
 		result = 0;
 		goto done;
@@ -2041,8 +2042,8 @@ varstrfastcmp_locale(Datum x, Datum y, SortSupport ssup)
 	 * We're likely to be asked to compare the same strings repeatedly, and
 	 * memcmp() is so much cheaper than strcoll() that it pays to try to cache
 	 * comparisons, even though in general there is no reason to think that
-	 * that will work out (every string datum may be unique).  Caching does not
-	 * slow things down measurably when it doesn't work out, and can speed
+	 * that will work out (every string datum may be unique).  Caching does
+	 * not slow things down measurably when it doesn't work out, and can speed
 	 * things up by rather a lot when it does.  In part, this is because the
 	 * memcmp() compares data from cachelines that are needed in L1 cache even
 	 * when the last comparison's result cannot be reused.
@@ -2158,8 +2159,8 @@ varstr_abbrev_convert(Datum original, SortSupport ssup)
 	 * abbreviate keys.  The full comparator for the C locale is always
 	 * memcmp().  It would be incorrect to allow bytea callers (callers that
 	 * always force the C collation -- bytea isn't a collatable type, but this
-	 * approach is convenient) to use strxfrm().  This is because bytea strings
-	 * may contain NUL bytes.  Besides, this should be faster, too.
+	 * approach is convenient) to use strxfrm().  This is because bytea
+	 * strings may contain NUL bytes.  Besides, this should be faster, too.
 	 *
 	 * More generally, it's okay that bytea callers can have NUL bytes in
 	 * strings because varstrcmp_abbrev() need not make a distinction between
@@ -2172,13 +2173,13 @@ varstr_abbrev_convert(Datum original, SortSupport ssup)
 	 * usually be what is effectively a "length-wise" resolution there and
 	 * then.
 	 *
-	 * If that doesn't work out -- if all bytes in the longer string positioned
-	 * at or past the offset of the smaller string's (first) terminating NUL
-	 * are actually representative of NUL bytes in the authoritative binary
-	 * string (perhaps with some *terminating* NUL bytes towards the end of the
-	 * longer string iff it happens to still be small) -- then an authoritative
-	 * tie-breaker will happen, and do the right thing: explicitly consider
-	 * string length.
+	 * If that doesn't work out -- if all bytes in the longer string
+	 * positioned at or past the offset of the smaller string's (first)
+	 * terminating NUL are actually representative of NUL bytes in the
+	 * authoritative binary string (perhaps with some *terminating* NUL bytes
+	 * towards the end of the longer string iff it happens to still be small)
+	 * -- then an authoritative tie-breaker will happen, and do the right
+	 * thing: explicitly consider string length.
 	 */
 	if (sss->collate_c)
 		memcpy(pres, authoritative_data, Min(len, sizeof(Datum)));
@@ -2286,6 +2287,7 @@ varstr_abbrev_convert(Datum original, SortSupport ssup)
 	/* Cache result, perhaps saving an expensive strxfrm() call next time */
 	sss->cache_blob = true;
 done:
+
 	/*
 	 * Byteswap on little-endian machines.
 	 *