On Thu, Jun 15, 2017 at 7:43 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Mon, Jun 12, 2017 at 10:08 AM, Ashutosh Sharma <ashu.coe...@gmail.com> 
> wrote:
>> PFA patch that fixes the issue described in above thread. As mentioned
>> in the above thread, the crash is basically happening in varstr_cmp()
>> function and  it's  only happening on Windows because in varstr_cmp(),
>> if the collation provider is ICU, we don't even think of calling ICU
>> functions to compare the string. Infact, we directly attempt to call
>> the OS function wsccoll*() which is not expected. Thanks.
> Your analysis is right, basically, when ICU is enabled we need to use
> ICU related functions and use corresponding information in the
> pg_locale structure. However, I see few problems with your patch.
> + if (mylocale)
> + {
> + if (mylocale->provider == COLLPROVIDER_ICU)
> + {
> +#ifdef USE_ICU
> + if (GetDatabaseEncoding() == PG_UTF8)
> + {
> + UErrorCode status;
> +
> + status = U_ZERO_ERROR;
> + result = ucol_strcollUTF8(mylocale->info.icu.ucol,
> +  arg1, len1,
> +  arg2, len2,
> +  &status);
> On Windows, we need to map UTF-8 strings to UTF-16 as we are doing in
> this function for other Windows specific comparisons for UTF-8
> strings.  Also, we don't want to screw memcmp optimization we have in
> this function, so do this ICU specific checking after memcmp check.

Firstly, thanks for reviewing the patch. Okay, we do map UTF-8 strings
to UTF-16 on windows. But, I think, we only do that when calling OS
(wcscoll*) functions for string comparison. Please correct me if i am
wrong here. In my case, i am using ICU functions for comparing strings
and i am not sure if we need the convert UTF-8 strings to UTF-16.

With Regards,
Ashutosh Sharma

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to