On 9/21/17 15:21, Peter Geoghegan wrote:
> On Thu, Sep 21, 2017 at 12:12 PM, Peter Eisentraut
> <peter.eisentr...@2ndquadrant.com> wrote:
>>> Attached patch shows what I'm getting at. This is untested, since I
>>> don't use Windows. Proceed with caution.
>>
>> Your analysis makes sense, but the patch doesn't work, because "locale"
>> is never set before reading it.
>
> It was just for illustrative purposes. Seems fine to actually move the
> WIN32 block down to just before the existing TRUST_STRXFRM test, since
> the locale is going to be cached and then immediately reused where we
> return immediately (Windows libc) anyway. This would also be a win for
> clarity, IMV.
I agree. The attached patch should do it.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From c2c875fe447eaf65f2ba5b28e77dcc2e42016455 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <pete...@gmx.net>
Date: Fri, 22 Sep 2017 10:23:35 -0400
Subject: [PATCH v2] Allow ICU to use SortSupport on Windows with UTF-8
There is no reason to ever prevent the use of SortSupport on Windows
when ICU locales are used. We previously avoided SortSupport on Windows
with UTF-8 server encoding and a non C-locale due to restrictions in
Windows' libc functionality.
This is now considered to be a restriction in one platform's libc
collation provider, and not a more general platform restriction.
Reported-by: Peter Geoghegan <p...@bowt.ie>
---
src/backend/utils/adt/varlena.c | 25 +++++++++++++++----------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/src/backend/utils/adt/varlena.c b/src/backend/utils/adt/varlena.c
index ebfb823fb8..071bc83378 100644
--- a/src/backend/utils/adt/varlena.c
+++ b/src/backend/utils/adt/varlena.c
@@ -1823,12 +1823,6 @@ varstr_sortsupport(SortSupport ssup, Oid collid, bool
bpchar)
* requirements of BpChar callers. However, if LC_COLLATE = C, we can
* make things quite a bit faster with varstrfastcmp_c or
bpcharfastcmp_c,
* both of which use memcmp() rather than strcoll().
- *
- * There is a further exception on Windows. When the database encoding
is
- * UTF-8 and we are not using the C collation, complex hacks are
required.
- * We don't currently have a comparator that handles that case, so we
fall
- * back on the slow method of having the sort code invoke bttextcmp()
(in
- * the case of text) via the fmgr trampoline.
*/
if (lc_collate_is_c(collid))
{
@@ -1839,10 +1833,6 @@ varstr_sortsupport(SortSupport ssup, Oid collid, bool
bpchar)
collate_c = true;
}
-#ifdef WIN32
- else if (GetDatabaseEncoding() == PG_UTF8)
- return;
-#endif
else
{
ssup->comparator = varstrfastcmp_locale;
@@ -1869,6 +1859,21 @@ varstr_sortsupport(SortSupport ssup, Oid collid, bool
bpchar)
}
}
+ /*
+ * There is a further exception on Windows. When the database encoding
is
+ * UTF-8 and we are not using the C collation, complex hacks are
required.
+ * We don't currently have a comparator that handles that case, so we
fall
+ * back on the slow method of having the sort code invoke bttextcmp()
(in
+ * the case of text) via the fmgr trampoline. ICU locales work just the
+ * same on Windows, however.
+ */
+#ifdef WIN32
+ if (!collate_c &&
+ GetDatabaseEncoding() == PG_UTF8 &&
+ !(locale && locale->provider == COLLPROVIDER_ICU))
+ return;
+#endif
+
/*
* Unfortunately, it seems that abbreviation for non-C collations is
* broken on many common platforms; testing of multiple versions of
glibc
--
2.14.1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
