Re: Chars problem restoring to ps 8.4 (utf8) a dumped db from ps 8.1 (latin9)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Chars problem restoring to ps 8.4 (utf8) a dumped db from ps 8.1 (latin9)
Дата
Msg-id 15506.1439388735@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Chars problem restoring to ps 8.4 (utf8) a dumped db from ps 8.1 (latin9)  (Adrian Klaver <adrian.klaver@aklaver.com>)
Ответы Re: Chars problem restoring to ps 8.4 (utf8) a dumped db from ps 8.1 (latin9)
Список 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 по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: Chars problem restoring to ps 8.4 (utf8) a dumped db from ps 8.1 (latin9)
Следующее
От: Edson Richter
Дата:
Сообщение: Sync replication + high latency server