Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit a95ff1f

Browse files
committed
Slightly refactor varstr_sortsupport() to improve readability.
Author: Andreas Karlsson Discussion: https://postgr.es/m/69c2a864-846f-4309-bd5a-aaa1c34f9a11@proxel.se
1 parent 15c1abd commit a95ff1f

File tree

1 file changed

+18
-18
lines changed

1 file changed

+18
-18
lines changed

src/backend/utils/adt/varlena.c

Lines changed: 18 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -1917,25 +1917,25 @@ varstr_sortsupport(SortSupport ssup, Oid typid, Oid collid)
19171917
}
19181918
else
19191919
ssup->comparator = varlenafastcmp_locale;
1920-
}
19211920

1922-
/*
1923-
* Unfortunately, it seems that abbreviation for non-C collations is
1924-
* broken on many common platforms; see pg_strxfrm_enabled().
1925-
*
1926-
* Even apart from the risk of broken locales, it's possible that there
1927-
* are platforms where the use of abbreviated keys should be disabled at
1928-
* compile time. Having only 4 byte datums could make worst-case
1929-
* performance drastically more likely, for example. Moreover, macOS's
1930-
* strxfrm() implementation is known to not effectively concentrate a
1931-
* significant amount of entropy from the original string in earlier
1932-
* transformed blobs. It's possible that other supported platforms are
1933-
* similarly encumbered. So, if we ever get past disabling this
1934-
* categorically, we may still want or need to disable it for particular
1935-
* platforms.
1936-
*/
1937-
if (!collate_c && !pg_strxfrm_enabled(locale))
1938-
abbreviate = false;
1921+
/*
1922+
* Unfortunately, it seems that abbreviation for non-C collations is
1923+
* broken on many common platforms; see pg_strxfrm_enabled().
1924+
*
1925+
* Even apart from the risk of broken locales, it's possible that there
1926+
* are platforms where the use of abbreviated keys should be disabled at
1927+
* compile time. Having only 4 byte datums could make worst-case
1928+
* performance drastically more likely, for example. Moreover, macOS's
1929+
* strxfrm() implementation is known to not effectively concentrate a
1930+
* significant amount of entropy from the original string in earlier
1931+
* transformed blobs. It's possible that other supported platforms are
1932+
* similarly encumbered. So, if we ever get past disabling this
1933+
* categorically, we may still want or need to disable it for particular
1934+
* platforms.
1935+
*/
1936+
if (!pg_strxfrm_enabled(locale))
1937+
abbreviate = false;
1938+
}
19391939

19401940
/*
19411941
* If we're using abbreviated keys, or if we're using a locale-aware

0 commit comments

Comments
 (0)