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

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
>

In response to

Responses

Browse pgsql-hackers by date

  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