Skip to content

P
Postgres FD Implementation
Commit 0231f838 authored by Tom Lane's avatar Tom Lane
Browse files
Options

Re-pgindent varlena.c. 

Just to make sure previous commit worked ...
parent 58e79721
Hide whitespace changes
Inline Side-by-side
Showing with 30 additions and 28 deletions
src/backend/utils/adt/varlena.c
View file @ 0231f838
......@@ -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.
*
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment