Slightly refactor varstr_sortsupport() to improve readability.
authorJeff Davis <jdavis@postgresql.org>
Tue, 20 Aug 2024 21:29:34 +0000 (14:29 -0700)
committerJeff Davis <jdavis@postgresql.org>
Tue, 20 Aug 2024 22:32:39 +0000 (15:32 -0700)
Author: Andreas Karlsson
Discussion: https://postgr.es/m/69c2a864-846f-4309-bd5a-aaa1c34f9a11@proxel.se

src/backend/utils/adt/varlena.c

index 4f9a676c9393a441ae62f0784657838bb59e4168..973034548d253f35b984cdfbbf24be62d000950f 100644 (file)
@@ -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