Re: ALTER TABLE ... IF EXISTS feature?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Farina <drfarina(at)acm(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Noah Zoschke <noah(at)heroku(dot)com>
Subject: Re: ALTER TABLE ... IF EXISTS feature?
Date: 2010-11-05 20:31:47
Message-ID: 1242.1288989107@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Farina <drfarina(at)acm(dot)org> writes:
> On Fri, Nov 5, 2010 at 11:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Daniel Farina <drfarina(at)acm(dot)org> writes:
>>> pg_dump --clean will successfully and silently wipe out a foreign key
>>> right now, should it exist,
>>
>> No, it will not, because we don't use CASCADE in the drop commands.

> I know it does not use CASCADE, but if I understand it correctly,
> foreign keys are dropped between tables, and then the tables are
> dropped. (effectively a manual cascade)

You're missing the point. The scenario I'm concerned about is:

source database contained table foo

target database contains table foo, and table bar, and
bar has an FK reference to foo

The FK constraint is not known to pg_dump, and therefore there will not
be a DROP CONSTRAINT for it in the dump. So the DROP on the referenced
table will fail. The only way we could make it succeed would be to use
CASCADE, which we don't do specifically because this sort of thing seems
quite unsafe.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2010-11-05 20:36:34 Re: Query Plan Columns
Previous Message David E. Wheeler 2010-11-05 20:27:21 Query Plan Columns