diff options
| -rw-r--r-- | src/backend/utils/adt/varlena.c | 58 |
1 files changed, 30 insertions, 28 deletions
diff --git a/src/backend/utils/adt/varlena.c b/src/backend/utils/adt/varlena.c index ed0a20a629c..f61e41ed7f1 100644 --- a/src/backend/utils/adt/varlena.c +++ b/src/backend/utils/adt/varlena.c @@ -93,7 +93,7 @@ typedef struct #define DatumGetVarStringPP(X) ((VarString *) PG_DETOAST_DATUM_PACKED(X)) static int varstrfastcmp_c(Datum x, Datum y, SortSupport ssup); -static int bpcharfastcmp_c(Datum x, Datum y, SortSupport ssup); +static int bpcharfastcmp_c(Datum x, Datum y, SortSupport ssup); static int varstrfastcmp_locale(Datum x, Datum y, SortSupport ssup); static int varstrcmp_abbrev(Datum x, Datum y, SortSupport ssup); static Datum varstr_abbrev_convert(Datum original, SortSupport ssup); @@ -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 @@ -1979,9 +1980,9 @@ bpcharfastcmp_c(Datum x, Datum y, SortSupport ssup) static int varstrfastcmp_locale(Datum x, Datum y, SortSupport ssup) { - VarString *arg1 = DatumGetVarStringPP(x); - VarString *arg2 = DatumGetVarStringPP(y); - bool arg1_match; + VarString *arg1 = DatumGetVarStringPP(x); + VarString *arg2 = DatumGetVarStringPP(y); + bool arg1_match; VarStringSortSupport *sss = (VarStringSortSupport *) ssup->ssup_extra; /* working state */ @@ -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. @@ -2135,8 +2136,8 @@ static Datum varstr_abbrev_convert(Datum original, SortSupport ssup) { VarStringSortSupport *sss = (VarStringSortSupport *) ssup->ssup_extra; - VarString *authoritative = DatumGetVarStringPP(original); - char *authoritative_data = VARDATA_ANY(authoritative); + VarString *authoritative = DatumGetVarStringPP(original); + char *authoritative_data = VARDATA_ANY(authoritative); /* working state */ Datum res; @@ -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. * |