Message-ID: <4A944698.8060908@hsolutions.ch>
Date: Tue, 25 Aug 2009 22:16:24 +0200
From: Denis BUCHER <dbucherml@hsolutions.ch>
Organization: Horus Digital Solutions =?UTF-8?B?U8Ogcmw=?=
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: pgsql-sql@postgresql.org
Subject: Re: Question about encoding
References: <4A92C305.2020303@hsolutions.ch>
	<1251153745.29824.19.camel@vanquo.pezone.net>
In-Reply-To: <1251153745.29824.19.camel@vanquo.pezone.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Hello,

Peter Eisentraut a écrit :
>> Question 1 :
>> Is it the expected behavior ? These characters have a SQL_ASCII
>> equivalent because I already have them stored in another table of the
>> same database
> 
> SQL_ASCII is not the same as ASCII.  SQL_ASCII means, take the bytes as
> they come.  So a 40-character UTF-8 string might indeed be longer than
> 40 bytes, which is what SQL_ASCII will look at.
> 
> The best bet is to avoid SQL_ASCII altogether.  It's pretty bogus and
> inconsistent.

OK that's a good point it explains everything.

>> Question 2 :
>> If yes, then I suppose I should have the database as LATIN1 or UTF8.
>> Can I change/convert the encoding of the database ? Or at least of the
>> schema (which would be even better)
> 
> Dump, recreate database with right encoding, restore.

Ok I did it but postgresql 7.4 was not very nice, the following failed :
1. dump
2. DROP DATABASE; CREATE DATABASE WITH ENCODING UTF8
3. restore

And it bugged. In fact the dump was writtent with "SET CLIENT
ENCODING=SQL_ASCII but when restoring on the UTF8 databse it failed, I
had to change it to SET client_encoding = LATIN1.

Anyway, finally everything is working again, I just had to add a SET
NAMES LATIN1 to my application because it was ISO and not UTF8 aware.

Therefore thanks a lot for your help, it solved all my problems !

Denis