Slightly refactor varstr_sortsupport() to improve readability.

Author: Andreas Karlsson
Discussion: https://postgr.es/m/69c2a864-846f-4309-bd5a-aaa1c34f9a11@proxel.se

diff --git a/src/backend/utils/adt/varlena.c b/src/backend/utils/adt/varlena.c
index 4f9a676c9393a441ae62f0784657838bb59e4168..973034548d253f35b984cdfbbf24be62d000950f 100644 (file)
--- 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