From a95ff1fe2eb4926b13e0940ad1f37d048704bdb0 Mon Sep 17 00:00:00 2001 From: Jeff Davis Date: Tue, 20 Aug 2024 14:29:34 -0700 Subject: [PATCH] Slightly refactor varstr_sortsupport() to improve readability. Author: Andreas Karlsson Discussion: https://postgr.es/m/69c2a864-846f-4309-bd5a-aaa1c34f9a11@proxel.se --- src/backend/utils/adt/varlena.c | 36 ++++++++++++++++----------------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/src/backend/utils/adt/varlena.c b/src/backend/utils/adt/varlena.c index 4f9a676c939..973034548d2 100644 --- a/src/backend/utils/adt/varlena.c +++ b/src/backend/utils/adt/varlena.c @@ -1917,25 +1917,25 @@ varstr_sortsupport(SortSupport ssup, Oid typid, Oid collid) } else ssup->comparator = varlenafastcmp_locale; - } - /* - * Unfortunately, it seems that abbreviation for non-C collations is - * broken on many common platforms; see pg_strxfrm_enabled(). - * - * Even apart from the risk of broken locales, it's possible that there - * are platforms where the use of abbreviated keys should be disabled at - * compile time. Having only 4 byte datums could make worst-case - * performance drastically more likely, for example. Moreover, macOS's - * strxfrm() implementation is known to not effectively concentrate a - * significant amount of entropy from the original string in earlier - * transformed blobs. It's possible that other supported platforms are - * similarly encumbered. So, if we ever get past disabling this - * categorically, we may still want or need to disable it for particular - * platforms. - */ - if (!collate_c && !pg_strxfrm_enabled(locale)) - abbreviate = false; + /* + * Unfortunately, it seems that abbreviation for non-C collations is + * broken on many common platforms; see pg_strxfrm_enabled(). + * + * Even apart from the risk of broken locales, it's possible that there + * are platforms where the use of abbreviated keys should be disabled at + * compile time. Having only 4 byte datums could make worst-case + * performance drastically more likely, for example. Moreover, macOS's + * strxfrm() implementation is known to not effectively concentrate a + * significant amount of entropy from the original string in earlier + * transformed blobs. It's possible that other supported platforms are + * similarly encumbered. So, if we ever get past disabling this + * categorically, we may still want or need to disable it for particular + * platforms. + */ + if (!pg_strxfrm_enabled(locale)) + abbreviate = false; + } /* * If we're using abbreviated keys, or if we're using a locale-aware