Re: Chars problem restoring to ps 8.4 (utf8) a dumped db from ps 8.1 (latin9) - Mailing list pgsql-general

From Tom Lane
Subject Re: Chars problem restoring to ps 8.4 (utf8) a dumped db from ps 8.1 (latin9)
Date
Msg-id 15506.1439388735@sss.pgh.pa.us
Whole thread Raw
In response to Re: Chars problem restoring to ps 8.4 (utf8) a dumped db from ps 8.1 (latin9)  (Adrian Klaver <adrian.klaver@aklaver.com>)
Responses Re: Chars problem restoring to ps 8.4 (utf8) a dumped db from ps 8.1 (latin9)
List pgsql-general
Adrian Klaver <adrian.klaver@aklaver.com> writes:
> On 08/12/2015 06:46 AM, Bianchi Quota Leonardo wrote:
>> I "SOLVED" it doing this way but don't know what I did and I don't know which consequences would have in future,
thenI need to know if it's ok... 
>>
>> Starting on BOX1
>> $pg_dump --no-privileges --no-owner -h localhost -U bugs -f DB.sql   (dump in latin9)
>>
>> $vi DB.sql and changed the first string with the last.
>> >SET client_encoding = 'LATIN9';
>> <SET client_encoding = 'utf8';

It does not seem likely to me that this would work at all.  You're taking
a dump file that is full of LATIN9 data and simply asserting that it's
UTF8 data.  That doesn't make it so.  If it seemed to work, maybe that's
because your editor changed the encoding?  Not to be relied on, for sure.

The right way to do something like this is not to change the dump file at
all, just create a new database with the encoding you want and restore
the dump file into it.  PG will handle the encoding conversion
automatically, as long as you don't misinform it about what encoding the
incoming data is in.

            regards, tom lane


pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: Chars problem restoring to ps 8.4 (utf8) a dumped db from ps 8.1 (latin9)
Next
From: Edson Richter
Date:
Subject: Sync replication + high latency server