Re: BUG #4319: lower()/upper() does not know about UNICODE case mapping - Mailing list pgsql-bugs

From valgog
Subject Re: BUG #4319: lower()/upper() does not know about UNICODE case mapping
Date
Msg-id 6efd98b6-d5d4-48f8-93f7-333372cb4cc6@m3g2000hsc.googlegroups.com
Whole thread Raw
In response to BUG #4319: lower()/upper() does not know about UNICODE case mapping  ("Valentine Gogichashvili" <valgog@gmail.com>)
Responses Re: Re: BUG #4319: lower()/upper() does not know about UNICODE case mapping
List pgsql-bugs
On Jul 22, 11:53=A0am, pete...@gmx.net (Peter Eisentraut) wrote:
> Am Tuesday, 22. July 2008 schrieb valgog:
>
> > Why Postgres allows creating UNICODE database with the locale, that
> > can possibly corrupt my data?
>
> It doesn't allow it, as of 8.3. =A0In 8.2 it does, but we have fixed that=
, for
> the reasons that are becoming obvious to you now.
>
> Perhaps part of the problem is that en_EN isn't actually a valid locale, =
as
> far as I can tell, unless SUSE has invented a new country. :) =A0Try loca=
le -a
> and pick one from that list.
>
> --
> Sent via pgsql-bugs mailing list (pgsql-b...@postgresql.org)
> To make changes to your subscription:http://www.postgresql.org/mailpref/p=
gsql-bugs

Ok, I have checked in databases with locale set to one of the utf8
locales convert data correctly. But I still do not understand, why
postgres initdb allows using non-UTF8 locales together with UNICODE
database encoding.

Another question. Is it possible to change the current Database
LC_CTYPE on the database without recreating it with initdb and
reimporting all the data. I would rather prefer my indexes recreated,
rather then reimporting database (cannot afford such a long time out
of service :(

pgsql-bugs by date:

Previous
From: valgog
Date:
Subject: Re: BUG #4319: lower()/upper() does not know about UNICODE case mapping
Next
From: Tomasz Ostrowski
Date:
Subject: Re: Re: BUG #4319: lower()/upper() does not know about UNICODE case mapping