@@ -1922,16 +1922,16 @@ varstr_sortsupport(SortSupport ssup, Oid typid, Oid collid)
19221922 * Unfortunately, it seems that abbreviation for non-C collations is
19231923 * broken on many common platforms; see pg_strxfrm_enabled().
19241924 *
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.
1925+ * Even apart from the risk of broken locales, it's possible that
1926+ *there are platforms where the use of abbreviated keys should be
1927+ *disabled at compile time. Having only 4 byte datums could make
1928+ *worst-case performance drastically more likely, for example.
1929+ *Moreover, macOS's strxfrm() implementation is known to not
1930+ *effectively concentrate a significant amount of entropy from the
1931+ *original string in earlier transformed blobs. It's possible that
1932+ *other supported platforms are similarly encumbered. So, if we ever
1933+ *get past disabling this categorically, we may still want or need to
1934+ *disable it for particular platforms.
19351935 */
19361936if (!pg_strxfrm_enabled (locale ))
19371937abbreviate = false;