From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Josh Kupershmidt <schmiddy(at)gmail(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> |
Subject: | Re: patch: option --if-exists for pg_dump |
Date: | 2014-03-04 07:55:35 |
Message-ID: | CAFj8pRCw-jtbi+PLa5g3i32AcL_8N_GjS8T=TX+Qj_mfjB85oQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2014-03-04 08:28:38 | Re: gaussian distribution pgbench |
Previous Message | Pavel Stehule | 2014-03-04 07:52:37 | Re: psql: show only failed queries |