Re: Encoding question when dumping/restoring databases for upgrade

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: arsi(at)archie(dot)netg(dot)se
Cc: postgres general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Encoding question when dumping/restoring databases for upgrade
Date: 2009-08-13 17:36:45
Message-ID: 25740.1250185005@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

arsi(at)archie(dot)netg(dot)se writes:
> I am sitting on version 7.4.x and am going to upgrade to version 8.3.x.
>> From all I can read I should have no problem with actual format of the
> pgdump file (for actual dumping and restoring purposes) but I am having
> problems with encoding (which I was fairly sure I would). I have searched
> the web for solutions and one solution given (in one thread where Tom
> Lane answered) was to set the correct encoding in the version 8.3.x
> database.

> However, the default encoding in the version 8.3.x instance is currently
> UTF8 and I am happy with that (in fact, I would even want it to be
> UNICODE). The encoding for most of the databases in the version 7.4.x was
> LATIN1. Is there any way I can ignore the LATIN1 encoding and force the
> database to accept the UTF8 encoding of the new version 8.3.x instance?

Sure, you can load a latin1 dump into a utf8 database. However a
pg_dumpall script will try to recreate the databases with their
original encodings. You can either edit the script to adjust the
ENCODING options for the databases, or use pg_dump to dump the
databases one at a time and then load them into hand-created
databases on the receiving end.

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Sam Mason 2009-08-13 17:36:55 Re: Selecting rows by content of array type field
Previous Message Radoslaw Zielinski 2009-08-13 17:22:39 Re: 8.4.0 bug - failure to enforce a foreign key constraint