From 2616a5d300e5bb5a2838d2a065afa3740e08727f Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Tue, 6 May 2014 11:26:26 -0400 Subject: Remove tabs after spaces in C comments This was not changed in HEAD, but will be done later as part of a pgindent run. Future pgindent runs will also do this. Report by Tom Lane Backpatch through all supported branches, but not HEAD --- src/backend/regex/regc_pg_locale.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to '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 bc5ad3157a9..570719d13a7 100644 --- a/src/backend/regex/regc_pg_locale.c +++ b/src/backend/regex/regc_pg_locale.c @@ -23,7 +23,7 @@ * several implementation strategies depending on the situation: * * 1. In C/POSIX collations, we use hard-wired code. We can't depend on - * the functions since those will obey LC_CTYPE. Note that these + * the 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): @@ -35,10 +35,10 @@ * * 2b. In all other encodings, or on machines that lack , we use * the 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 * 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. -- cgit v1.2.3