Pavel Stehule escribió:
> 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.)
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.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services