#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);
*
* 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
#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
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 */
{
/*
* 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;
* 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.
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;
* 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
* 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)));
/* Cache result, perhaps saving an expensive strxfrm() call next time */
sss->cache_blob = true;
done:
+
/*
* Byteswap on little-endian machines.
*
projects / postgresql.git / commitdiff