Re: ALTER TABLE ... IF EXISTS feature?
От | Daniel Farina |
---|---|
Тема | Re: ALTER TABLE ... IF EXISTS feature? |
Дата | |
Msg-id | AANLkTi=2bUQ0YcrN+mfBd7No1Zw=wqgUJNHAU63RQ1My@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER TABLE ... IF EXISTS feature? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ALTER TABLE ... IF EXISTS feature?
|
Список | pgsql-hackers |
On Fri, Nov 5, 2010 at 1:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Daniel Farina <drfarina@acm.org> writes: >> On Fri, Nov 5, 2010 at 11:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Daniel Farina <drfarina@acm.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
В списке pgsql-hackers по дате отправления: