I've have a PostgreSQL database cluster that I've continually upgraded
from 7.1 to 9.1 without problems using pg_dumpall and psql. When
migrating to 9.2, I decided to change the default encoding for the
database cluster from SQL_ASCII to UTF8. When I went to restore my
database backup (created using 9.1's pg_dumpall), the tables
containing data not in UTF8 format were empty.
This appears to be caused by pg_dumpall omitting the ENCODING when
dumping if it is the same as the current database cluster's default
encoding. I believe this is a bad idea, as there is no guarantee the
backup will be restored on a cluster with the same default encoding.
This patch always sets the ENCODING for the databases, even if it is
the same as the current database cluster default encoding. Thoughts?
I'm not sure if similar changes should be made for LC_COLLATE or
LC_CTYPE, but that's something that should be considered.
Please CC me when responding as I don't currently subscribe to the
list.
Thanks,
Jeremy
diff --git src/bin/pg_dump/pg_dumpall.c src/bin/pg_dump/pg_dumpall.c
index ca95bad..fa81ab1 100644
--- src/bin/pg_dump/pg_dumpall.c
+++ src/bin/pg_dump/pg_dumpall.c
@@ -1310,11 +1310,8 @@ dumpCreateDB(PGconn *conn)
if (strlen(dbowner) != 0)
appendPQExpBuffer(buf, " OWNER = %s",
fmtId(dbowner));
- if (default_encoding && strcmp(dbencoding,
default_encoding) != 0)
- {
- appendPQExpBuffer(buf, " ENCODING = ");
- appendStringLiteralConn(buf, dbencoding, conn);
- }
+ appendPQExpBuffer(buf, " ENCODING = ");
+ appendStringLiteralConn(buf, dbencoding, conn);
if (default_collate && strcmp(dbcollate,
default_collate) != 0)
{
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
