From: | Tim Tassonis <timtas(at)cubic(dot)ch> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: initdb in 8.3 |
Date: | 2008-04-23 16:22:10 |
Message-ID: | 480F6232.9090108@cubic.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Martijn van Oosterhout wrote:
> On Wed, Apr 23, 2008 at 04:35:04PM +0200, Tim Tassonis wrote:
>>
>> If specifying a characterset different from the default locale for a
>> database is such a bad idea, why is it possible at all?
>
> It isn't possible, that's the point. What is possible is that client
> can use any encoding they like to talk to the server, but the server
> will store and manage it all in one. What locale C means "I'm an
> encoding wizard and will ensure all my programs can handle all the
> encodings I want to use, because I understand the database will treat
> everything I send as ASCII bytes no matter what encoding the clients
> say it is".
>
>> From how I understand you, if I wanted a postgres server machine
>> supporting databases with different charsets, I'm advised to initialise
>> one cluster per locale.
>
> If you want to control the *storage* charset, yes. If you just want
> clients to think it's a LATIN9 DB, doing a:
>
> ALTER DATABASE foo SET client_encoding=latin9;
Ok, got it, it's really this setting that's interesting. If I have a
legacy application that defaults to latin1, I can leave the DB to UTF-8
,set the client_encoding to latin1 and then all my selects and inserts
can use latin1, but the data will be stored in utf-8.
Well, that's really all I need, sorry for the confusion.
Thanks a lot
Tim
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Crawford | 2008-04-23 16:32:02 | Re: Need to update all my 60 million rows at once without transactional integrity |
Previous Message | Scott Marlowe | 2008-04-23 16:06:42 | Re: Vacuuming Questions |