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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
