I just received a feedback from our bug report about this problem and
it seems the problem also occurred on a windows machine.
http://pgfoundry.org/tracker/index.php?func=detail&aid=1010988&group_id=1000140&atid=590
On Sat, Mar 19, 2011 at 14:13, Marko Kreen <markokr@gmail.com> wrote:
> On Sat, Mar 19, 2011 at 5:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Marko Kreen <markokr@gmail.com> writes:
>>> On Sat, Mar 19, 2011 at 6:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> Or we could bite the bullet and start using str_tolower(), but the
>>>> performance implications of that are unpleasant; not to mention that
>>>> we really don't want to re-introduce the "Turkish problem" with
>>>> unexpected handling of i/I in identifiers.
>>
>>> How about first pass with 'a' - 'A' and if highbit is found
>>> then str_tolower()?
>>
>> Hm, maybe.
>>
>> There's still the problem of what to do in src/port/pgstrcasecmp.c,
>> which won't have the infrastructure needed to do that.
>
> You mean client-side? Could we have a str_tolower without xxx_l
> branch that always does wide-char conversion if high-bit is set?
>
> Custom locale there won't make sense there anyway?
>
> --
> marko
>
--
Regards,
Francisco Figueiredo Jr.
Npgsql Lead Developer
http://www.npgsql.org
http://fxjr.blogspot.com
http://twitter.com/franciscojunior
