Here are a few open concerns about pg_dump:
Critical:
* pg_dumpall is not compatible with pre-7.3. It used to be ignorant but
now that it has extra columns in pg_database and pg_user to take care of
it will break with older releases. This should be straightforward to fix
for me (I hope) within the next few days.
* pg_dumpall doesn't know about the new database-level privileges, yet.
Non-critical:
* The pg_dumpall documentation contains this:
| -c, --clean
|
| Include SQL commands to clean (drop) database objects before
| recreating them. (This option is fairly useless, since the output script
| expects to create the databases themselves; they would always be empty
| upon creation.)
pg_dumpall processes this option itself and puts out DROP DATABASE
commands for each database dumped, which seems to be a reasonable feature.
Perhaps the option should not be passed through to pg_dump (where it is
useless) and the documentation should be changed to reflect that.
* The --ignore-version description says that pg_dump only works with
servers of the same release. Nowadays we take great care to make it
backward compatible, so the documentation should be changed if we want to
publicize that.
* The "disable trigger" feature currently puts out code like this:
-- Disable triggers
UPDATE pg_catalog.pg_class SET reltriggers = 0 WHERE oid = 'char_tbl'::pg_catalog.regclass;
COPY char_tbl (f1) FROM stdin;
a
ab
abcd
abcd
\.
-- Enable triggers
UPDATE pg_catalog.pg_class SET reltriggers = (SELECT pg_catalog.count(*) FROM pg_catalog.pg_trigger where pg_class.oid
=tgrelid) WHERE oid = 'char_tbl'::pg_catalog.regclass;
As the pg_dump man page correctly advises, this may leave the system
catalogs corrupted if the restore is interrupted. I was wondering why we
don't do this:
BEGIN;
UPDATE ...
COPY ...
UPDATE ...
COMMIT;
--
Peter Eisentraut peter_e@gmx.net
