Re: ToDo: pg_backup - using a conditional DROP - Mailing list pgsql-hackers

From Robert Haas
Subject Re: ToDo: pg_backup - using a conditional DROP
Date
Msg-id CA+TgmoarBJAUXgFiB2Vf5ZfX=WT0ZmS_Eo392FD6kK=JHZ=k_A@mail.gmail.com
Whole thread Raw
In response to Re: ToDo: pg_backup - using a conditional DROP  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ToDo: pg_backup - using a conditional DROP
List pgsql-hackers
On Tue, Nov 15, 2011 at 9:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Pavel Stehule <pavel.stehule@gmail.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


pgsql-hackers by date:

Previous
From: Scott Mead
Date:
Subject: Re: IDLE in transaction introspection
Next
From: Yeb Havinga
Date:
Subject: Re: [PATCH] Unremovable tuple monitoring