postgres.git / summary / log / commit / refs

commit    a95ff1fe2eb4926b13e0940ad1f37d048704bdb0
Author:   Jeff Davis <jdavis@postgresql.org>
Date:     Tue Aug 20 21:29:34 2024 +0000
First released in: 18.0

    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


[parent: 15c1abd97710]