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 <mark...@gmail.com> wrote: > On Sat, Mar 19, 2011 at 5:05 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Marko Kreen <mark...@gmail.com> writes: >>> On Sat, Mar 19, 2011 at 6:10 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
