mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Re-pgindent varlena.c.

Browse Source 
Just to make sure previous commit worked ...
This commit is contained in:
Tom Lane 2016-02-08 15:17:40 -05:00
parent 58e797216f
commit 0231f83856
1 changed files with 30 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
src/backend/utils/adt/varlena.c
View File

@ -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
@ -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.
@ -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.
*