Hi,
On Thu, Jun 15, 2017 at 7:43 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Mon, Jun 12, 2017 at 10:08 AM, Ashutosh Sharma <ashu.coek88@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
> +#ifdef HAVE_UCOL_STRCOLLUTF8
> + 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
EnterpriseDB:http://www.enterprisedb.com