From: | Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, <pgman(at)candle(dot)pha(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: locale |
Date: | 2004-04-08 19:19:32 |
Message-ID: | Pine.LNX.4.44.0404082109340.4551-100000@zigo.dhs.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 8 Apr 2004, Tom Lane wrote:
> You're missing the point: strcoll() is not going to compare them as
> latin1 strings. It's going to interpret the bytes as utf-8 strings,
> because that's what LC_CTYPE will tell it to do.
My current understanding of what you are saying now is that LC_CTYPE is
always UTF-8 and all comparisons in the new database are going to be
wrong. This since all strings will be compared as if they where UTF-8.
LC_CTYPE is per cluster and not per database as some of the other LC_xxxx.
Yes, this actually makes sense. I really hope that this is the way it work
because I think I can understand this. I don't like it, but I can
understand what pg currently do, which is good (unless pg does something
else :-)
Thanks for the explanation.
--
/Dennis Björklund
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2004-04-08 20:44:46 | Re: PostgreSQL configuration |
Previous Message | Bruce Momjian | 2004-04-08 19:04:36 | Re: [HACKERS] Function to kill backend |