Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit0231f83

Browse files
committed
Re-pgindent varlena.c.
Just to make sure previous commit worked ...
1 parent58e7972 commit0231f83

File tree

1 file changed

+30
-28
lines changed

1 file changed

+30
-28
lines changed

‎src/backend/utils/adt/varlena.c

Lines changed: 30 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -93,7 +93,7 @@ typedef struct
9393
#defineDatumGetVarStringPP(X)((VarString *) PG_DETOAST_DATUM_PACKED(X))
9494

9595
staticintvarstrfastcmp_c(Datumx,Datumy,SortSupportssup);
96-
staticintbpcharfastcmp_c(Datumx,Datumy,SortSupportssup);
96+
staticintbpcharfastcmp_c(Datumx,Datumy,SortSupportssup);
9797
staticintvarstrfastcmp_locale(Datumx,Datumy,SortSupportssup);
9898
staticintvarstrcmp_abbrev(Datumx,Datumy,SortSupportssup);
9999
staticDatumvarstr_abbrev_convert(Datumoriginal,SortSupportssup);
@@ -1780,8 +1780,8 @@ varstr_sortsupport(SortSupport ssup, Oid collid, bool bpchar)
17801780
*
17811781
* Most typically, we'll set the comparator to varstrfastcmp_locale, which
17821782
* uses strcoll() to perform comparisons and knows about the special
1783-
* requirements of BpChar callers. However, if LC_COLLATE = C, we can make
1784-
* things quite a bit faster with varstrfastcmp_c or bpcharfastcmp_c,
1783+
* requirements of BpChar callers. However, if LC_COLLATE = C, we can
1784+
*makethings quite a bit faster with varstrfastcmp_c or bpcharfastcmp_c,
17851785
* both of which use memcmp() rather than strcoll().
17861786
*
17871787
* There is a further exception on Windows. When the database encoding is
@@ -1866,6 +1866,7 @@ varstr_sortsupport(SortSupport ssup, Oid collid, bool bpchar)
18661866
#ifdefHAVE_LOCALE_T
18671867
sss->locale=locale;
18681868
#endif
1869+
18691870
/*
18701871
* To avoid somehow confusing a strxfrm() blob and an original string,
18711872
* constantly keep track of the variety of data that buf1 and buf2
@@ -1979,9 +1980,9 @@ bpcharfastcmp_c(Datum x, Datum y, SortSupport ssup)
19791980
staticint
19801981
varstrfastcmp_locale(Datumx,Datumy,SortSupportssup)
19811982
{
1982-
VarString*arg1=DatumGetVarStringPP(x);
1983-
VarString*arg2=DatumGetVarStringPP(y);
1984-
boolarg1_match;
1983+
VarString*arg1=DatumGetVarStringPP(x);
1984+
VarString*arg2=DatumGetVarStringPP(y);
1985+
boolarg1_match;
19851986
VarStringSortSupport*sss= (VarStringSortSupport*)ssup->ssup_extra;
19861987

19871988
/* working state */
@@ -2002,16 +2003,16 @@ varstrfastcmp_locale(Datum x, Datum y, SortSupport ssup)
20022003
{
20032004
/*
20042005
* No change in buf1 or buf2 contents, so avoid changing last_len1 or
2005-
* last_len2. Existing contents of buffers might still be used by next
2006-
* call.
2006+
* last_len2. Existing contents of buffers might still be used by
2007+
*nextcall.
20072008
*
2008-
* It's fine to allow the comparison of BpChar padding bytes here, even
2009-
* though that implies that the memcmp() will usually be performed for
2010-
* BpChar callers (though multibyte characters could still prevent that
2011-
* from occurring). The memcmp() is still very cheap, and BpChar's
2012-
* funny semantics have us remove trailing spaces (not limited to
2013-
* padding), so we need make no distinction between padding space
2014-
* characters and "real" space characters.
2009+
* It's fine to allow the comparison of BpChar padding bytes here,
2010+
*eventhough that implies that the memcmp() will usually be
2011+
*performed forBpChar callers (though multibyte characters could
2012+
*still prevent thatfrom occurring). The memcmp() is still very
2013+
*cheap, and BpChar'sfunny semantics have us remove trailing spaces
2014+
*(not limited topadding), so we need make no distinction between
2015+
*padding spacecharacters and "real" space characters.
20152016
*/
20162017
result=0;
20172018
gotodone;
@@ -2041,8 +2042,8 @@ varstrfastcmp_locale(Datum x, Datum y, SortSupport ssup)
20412042
* We're likely to be asked to compare the same strings repeatedly, and
20422043
* memcmp() is so much cheaper than strcoll() that it pays to try to cache
20432044
* comparisons, even though in general there is no reason to think that
2044-
* that will work out (every string datum may be unique). Caching does not
2045-
* slow things down measurably when it doesn't work out, and can speed
2045+
* that will work out (every string datum may be unique). Caching does
2046+
*notslow things down measurably when it doesn't work out, and can speed
20462047
* things up by rather a lot when it does. In part, this is because the
20472048
* memcmp() compares data from cachelines that are needed in L1 cache even
20482049
* when the last comparison's result cannot be reused.
@@ -2135,8 +2136,8 @@ static Datum
21352136
varstr_abbrev_convert(Datumoriginal,SortSupportssup)
21362137
{
21372138
VarStringSortSupport*sss= (VarStringSortSupport*)ssup->ssup_extra;
2138-
VarString*authoritative=DatumGetVarStringPP(original);
2139-
char*authoritative_data=VARDATA_ANY(authoritative);
2139+
VarString*authoritative=DatumGetVarStringPP(original);
2140+
char*authoritative_data=VARDATA_ANY(authoritative);
21402141

21412142
/* working state */
21422143
Datumres;
@@ -2158,8 +2159,8 @@ varstr_abbrev_convert(Datum original, SortSupport ssup)
21582159
* abbreviate keys. The full comparator for the C locale is always
21592160
* memcmp(). It would be incorrect to allow bytea callers (callers that
21602161
* always force the C collation -- bytea isn't a collatable type, but this
2161-
* approach is convenient) to use strxfrm(). This is because bytea strings
2162-
* may contain NUL bytes. Besides, this should be faster, too.
2162+
* approach is convenient) to use strxfrm(). This is because bytea
2163+
*stringsmay contain NUL bytes. Besides, this should be faster, too.
21632164
*
21642165
* More generally, it's okay that bytea callers can have NUL bytes in
21652166
* strings because varstrcmp_abbrev() need not make a distinction between
@@ -2172,13 +2173,13 @@ varstr_abbrev_convert(Datum original, SortSupport ssup)
21722173
* usually be what is effectively a "length-wise" resolution there and
21732174
* then.
21742175
*
2175-
* If that doesn't work out -- if all bytes in the longer string positioned
2176-
* at or past the offset of the smaller string's (first) terminating NUL
2177-
* are actually representative of NUL bytes in the authoritative binary
2178-
* string (perhaps with some *terminating* NUL bytes towards the end of the
2179-
* longer string iff it happens to still be small) -- then an authoritative
2180-
* tie-breaker will happen, and do the right thing: explicitly consider
2181-
* string length.
2176+
* If that doesn't work out -- if all bytes in the longer string
2177+
*positionedat or past the offset of the smaller string's (first)
2178+
*terminating NULare actually representative of NUL bytes in the
2179+
*authoritative binarystring (perhaps with some *terminating* NUL bytes
2180+
*towards the end of thelonger string iff it happens to still be small)
2181+
*-- then an authoritativetie-breaker will happen, and do the right
2182+
*thing: explicitly considerstring length.
21822183
*/
21832184
if (sss->collate_c)
21842185
memcpy(pres,authoritative_data,Min(len,sizeof(Datum)));
@@ -2286,6 +2287,7 @@ varstr_abbrev_convert(Datum original, SortSupport ssup)
22862287
/* Cache result, perhaps saving an expensive strxfrm() call next time */
22872288
sss->cache_blob= true;
22882289
done:
2290+
22892291
/*
22902292
* Byteswap on little-endian machines.
22912293
*

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp