pgindent run for 9.4

[postgresql] / src / backend / regex / regc_pg_locale.c

diff --git a/src/backend/regex/regc_pg_locale.c b/src/backend/regex/regc_pg_locale.c
index 425c278de4363b3a72a71b0f91654fd2f838004c..6b2e38e165dbb3a03928416fc5e15f196ab8a251 100644 (file)
--- a/src/backend/regex/regc_pg_locale.c
+++ b/src/backend/regex/regc_pg_locale.c
@@ -24,7 +24,7 @@
  * several implementation strategies depending on the situation:
  *
  * 1. In C/POSIX collations, we use hard-wired code.  We can't depend on
- * the <ctype.h> functions since those will obey LC_CTYPE.     Note that these
+ * the <ctype.h> functions since those will obey LC_CTYPE.  Note that these
  * collations don't give a fig about multibyte characters.
  *
  * 2. In the "default" collation (which is supposed to obey LC_CTYPE):
@@ -36,10 +36,10 @@
  *
  * 2b. In all other encodings, or on machines that lack <wctype.h>, we use
  * the <ctype.h> functions for pg_wchar values up to 255, and punt for values
- * above that. This is only 100% correct in single-byte encodings such as
- * LATINn.     However, non-Unicode multibyte encodings are mostly Far Eastern
+ * above that.  This is only 100% correct in single-byte encodings such as
+ * LATINn.  However, non-Unicode multibyte encodings are mostly Far Eastern
  * character sets for which the properties being tested here aren't very
- * relevant for higher code values anyway.     The difficulty with using the
+ * relevant for higher code values anyway.  The difficulty with using the
  * <wctype.h> functions with non-Unicode multibyte encodings is that we can
  * have no certainty that the platform's wchar_t representation matches
  * what we do in pg_wchar conversions.
@@ -730,7 +730,7 @@ store_match(pg_ctype_cache *pcc, pg_wchar chr1, int nchrs)
 
 /*
  * Given a probe function (e.g., pg_wc_isalpha) get a struct cvec for all
- * chrs satisfying the probe function. The active collation is the one
+ * chrs satisfying the probe function.  The active collation is the one
  * previously set by pg_set_regex_collation.  Return NULL if out of memory.
  *
  * Note that the result must not be freed or modified by caller.
@@ -777,7 +777,7 @@ pg_ctype_get_cache(pg_wc_probefunc probefunc)
         * UTF8 go up to 0x7FF, which is a pretty arbitrary cutoff but we cannot
         * extend it as far as we'd like (say, 0xFFFF, the end of the Basic
         * Multilingual Plane) without creating significant performance issues due
-        * to too many characters being fed through the colormap code.  This will
+        * to too many characters being fed through the colormap code.  This will
         * need redesign to fix reasonably, but at least for the moment we have
         * all common European languages covered.  Otherwise (not C, not UTF8) go
         * up to 255.  These limits are interrelated with restrictions discussed