On Mon, Oct 15, 2007 at 07:44:00PM +0200, Magnus Hagander wrote:
> Tom Lane wrote:
> > Magnus Hagander <magnus@hagander.net> writes:
> >> Tom Lane wrote:
> >>> Hmm. If it doesn't need a special case, then we still lack an
> >>> explanation for the aforementioned bug report.
> >
> >> From what I can tell that report doesn't tell us very much - we don't
> >> know server encoding, we don't know server locale, we don't even know
> >> client encoding. So I don't think we know anywhere *near* enough to say
> >> it's related to this.
> >
> > In the followup we found out that he was using UTF-8 encoding:
> > http://archives.postgresql.org/pgsql-bugs/2007-05/msg00264.php
> > So while that report certainly left a great deal to be desired in terms
> > of precision, my gut tells me it's related. Has anyone tried to
> > reproduce that behavior by initdb'ing 8.2 in a suitable UTF-8-using
> > Windows locale?
>
> It doesn't tell us if it's the client or the server that's in UTF8, and
> it doesn't tell us about the locale.
>
> Euler Taveira de Oliveira's response says he can't reproduce it. I
> haven't tried myself, and that webpage really doesn't tell us what what
> the character is. If someone can comment on that, I can try to repro it
> on my systems.
Got some help on IRC to dentify the charafters as ç and Ç.
I can confirm that both work perfectly fine with UTF-8 and locale
Swedish_Sweden.1252. They sort correctly, and they work with both upper()
and lower() correctly.
This test is with 8.3-HEAD and the patch to allow UTF-8.
This leads me to beleive that something is wrong with the ops system. Most
likely it's just the client that's in UTF8 mode, and the server is
SQL_ASCII.
//Magnus