Skip site navigation (1) Skip section navigation (2)

Re: Recommended approach for upgrading DBs with nonmatching encodings

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martin Pitt <martin(at)piware(dot)de>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: Recommended approach for upgrading DBs with nonmatching encodings
Date: 2008-03-30 21:15:19
Message-ID: 28933.1206911719@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Martin Pitt <martin(at)piware(dot)de> writes:
> Tom Lane [2008-03-30 16:43 -0400]:
>> Huh?  Please provide a test case.

> Ah, I got it. This fails:

>   pg_dump -Fc -E UTF8 -p 5432  latin1test | pg_restore -p 5433 -d template1 -C

> (5432 is 8.1, 5433 is 8.3, both with locale ru_RU.UTF-8; 
> createdb -E latin1 latin1test)

Yeah.  This will try to create the new latin1test with all the same
properties it had before, including encoding, and 8.3 intentionally
rejects that.  Your 8.1 setup is pretty broken too (it will misbehave
in various ways because of the encoding mismatch), but 8.1 fails to
realize that.

> In that case I do not even need to specify -E. Seems that
> pg_dump/pg_restore are clever enough to detect encodings and necessary
> conversions.

Yeah, there's usually little value in -E unless you're planning to
do something else with the dump than just feed it to pg_restore.
(If you wanted to export to some other DBMS, for example, it could
be useful.)  In particular -E has entirely zip bearing on what
database encoding will be assigned during restore.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Martin PittDate: 2008-03-31 06:22:49
Subject: Re: Recommended approach for upgrading DBs with nonmatchingencodings
Previous:From: Martin PittDate: 2008-03-30 20:58:47
Subject: Re: Recommended approach for upgrading DBs with nonmatchingencodings

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group