Re: ToDo: pg_backup - using a conditional DROP

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ToDo: pg_backup - using a conditional DROP
Date: 2011-11-15 14:59:17
Message-ID: CA+TgmoarBJAUXgFiB2Vf5ZfX=WT0ZmS_Eo392FD6kK=JHZ=k_A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 15, 2011 at 9:14 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> there is a request on enhancing of pg_backup to produce a conditional
>> DROPs. A reason for this request is more simple usage in very dynamic
>> production - cloud BI solution.
>
>> pg_backup can have a new option "--conditional-drops" and then pg_dump
>> will produce a DROP IF EXISTS statements instead DROP statements.
>
> That is not going to be possible unless we commit to having an IF EXISTS
> option for every type of DROP statement, now and in the future.
> Even then, it's not apparent to me that it solves any real use-case.
> You're probably better off just using --clean and ignoring any errors.

Ignoring errors sucks, though, because sometimes you want the whole
thing to succeed or fail as a unit.

I'm wondering why we need an option for this, though. Assuming we
make DROP IF EXISTS work anywhere that it doesn't already, why not
just always produce that rather than straight DROP? It seems
categorically better.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yeb Havinga 2011-11-15 15:05:35 Re: [PATCH] Unremovable tuple monitoring
Previous Message Scott Mead 2011-11-15 14:44:06 Re: IDLE in transaction introspection