From: | Denis BUCHER <dbucherml(at)hsolutions(dot)ch> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Question about encoding |
Date: | 2009-08-25 20:16:24 |
Message-ID: | 4A944698.8060908@hsolutions.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Nacef LABIDI | 2009-08-26 13:19:38 | Selecting values from comma separated string |
Previous Message | Peter Eisentraut | 2009-08-24 22:42:25 | Re: Question about encoding |