Hi, 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 > +#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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers