> This patch has redesigned implementation --if-exists for pg_dumpall. Now it > is not propagated to pg_dump, but used on pg_dumpall level.
Seems sane, thanks.
BTW after this patch, I still don't see an error-free output from restoring a database on top of itself. One problem is plpgsql, which is now an extension, so pg_dump emits this error message:
ERROR: cannot drop language plpgsql because extension plpgsql requires it SUGERENCIA: You can drop extension plpgsql instead.
Another problem is that some DROP commands don't work. For instance, if the public schema in the target database contains objects that haven't been dropped yet, the DROP command will fail:
ERROR: cannot drop schema public because other objects depend on it DETALLE: function bt_metap(text) depends on schema public function bt_page_items(text,integer) depends on schema public function bt_page_stats(text,integer) depends on schema public function f() depends on schema public function get_raw_page(text,integer) depends on schema public function heap_page_items(bytea) depends on schema public function locate_tuple_corruption() depends on schema public function page_header(bytea) depends on schema public SUGERENCIA: Use DROP ... CASCADE to drop the dependent objects too.
(The way I got this was by using my 8.2 installation, on which I ran the regression tests; then I dumped the resulting regression database. The database on which I restored wasn't clean, as it contained unrelated junk in the public schema.)
I'll recheck a behave of extensions.
I rechecked extensions and it works - so it can be full quiet when old dump is imported, but import dump from fresh dumps should to work.
Regards
Pavel
On second hand - usually, preferred way is using a dump related to target PostgreSQL release
Not sure what's the right answer here to this problem, but it cannot be attributed to this patch anyway.
I'm about to push this, since other than the above problems, this functionality seems to be working as designed.