Re-pgindent varlena.c.
Just to make sure previous commit worked ...
This commit is contained in:
Tom Lane
parent
58e797216f
commit
0231f83856
|
|
@ -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.
|
||||
*
|
||||
|
|
|
|||
Loading…
Reference in New Issue