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 14:16:11 |
Message-ID: | Pine.LNX.4.44.0404081559430.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:
> See my previous point: the index does not actually fail, in our current
> implementation, because strcoll() is unaffected by the database's
> encoding setting.
How can it be? If I have a utf-8 template1 and a table with an index
sorted according to the utf-8 characters in some locale. Then this table
and index is copied into a Latin1 database. When I interpret these bytes
as Latin1 in the index, the ordering does not have to be the same as it
was before and the index can not be used.
I don't understand what you mean when you say that strcoll() is unaffected
by the database's encoding setting. It interprets characters, how can it
not be?
If it works it must be something more going on that I don't
know/understand yet. If I am I would be happy to be corrected, if not we
have a more broken system then we expected before.
The objection to a per database locale is that we can not copy a table
from the template into the database since the index would not be valid
anymore. To me that is solvable by just reindexing. The current problem
with encodings does not look solvable at all to me (except to not copy
tables when we can not reencode the strings).
--
/Dennis Björklund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-04-08 14:31:44 | Re: PostgreSQL configuration |
Previous Message | Tom Lane | 2004-04-08 13:56:06 | Re: locale |