Did we ever address this?
---
Tom Lane wrote:
I've been able to reproduce the behavior described here:
http://archives.postgresql.org/pgsql-general/2011-03/msg00538.php
It's specific to UTF8 locales on Mac OS X. I'm not
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=detailaid=1010988group_id=1000140atid=590
On Sat, Mar 19, 2011 at 14:13, Marko Kreen mark...@gmail.com wrote:
On Sat, Mar
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
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
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
I've been able to reproduce the behavior described here:
http://archives.postgresql.org/pgsql-general/2011-03/msg00538.php
It's specific to UTF8 locales on Mac OS X. I'm not sure if the
problem can manifest anywhere else; considering that OS X's UTF8
locales have a general reputation of being
