Re: ALTER TABLE ... IF EXISTS feature?

From: Daniel Farina <drfarina(at)acm(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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:48:27
Message-ID: AANLkTi=2bUQ0YcrN+mfBd7No1Zw=wqgUJNHAU63RQ1My@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 5, 2010 at 1:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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
>

I think that's intended and okay to fail, and would continue to fail
post-patch, if I understand what I am doing correctly (always
suspect).

The only condition where this should be emitted is when all the
dependent objects are going to be dropped anyway.

fdr

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2010-11-05 20:51:53 Re: Query Plan Columns
Previous Message David E. Wheeler 2010-11-05 20:42:20 Re: Query Plan Columns