Re: patch: option --if-exists for pg_dump
От | Pavel Stehule |
---|---|
Тема | Re: patch: option --if-exists for pg_dump |
Дата | |
Msg-id | CAFj8pRCyr_JctGBRXAa8m94ARiQX7h7Yd5pLMFYAzRnDhqtk_A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: patch: option --if-exists for pg_dump (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | pgsql-hackers |
2014-03-04 8:55 GMT+01:00 Pavel Stehule <pavel.stehule@gmail.com>:
2014-03-03 18:18 GMT+01:00 Alvaro Herrera <alvherre@2ndquadrant.com>:Pavel Stehule escribió:> This patch has redesigned implementation --if-exists for pg_dumpall. Now itSeems sane, thanks.
> is not propagated to pg_dump, but used on pg_dumpall level.
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 releaseNot 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.Thank you very muchRegardsPavel--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: