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
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 |