Re: patch: option --if-exists for pg_dump

2014-03-04 8:55 GMT+01:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

>
>
>
> 2014-03-03 18:18 GMT+01:00 Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>:
>
> 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.)
>>
>>
> 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.
>>
>>
> Thank you very much
>
> Regards
>
> Pavel
>
>
>> --
>> Álvaro Herrera http://www.2ndQuadrant.com/
>> PostgreSQL Development, 24x7 Support, Training & Services
>>
>
>