Re: ALTER TABLE ... IF EXISTS feature?
От | Robert Haas |
---|---|
Тема | Re: ALTER TABLE ... IF EXISTS feature? |
Дата | |
Msg-id | AANLkTi=Eb4Oqr2vtEC1ViBhb4LM7S9jwDTpPtxNhZm3H@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER TABLE ... IF EXISTS feature? (Daniel Farina <drfarina@acm.org>) |
Ответы |
Re: ALTER TABLE ... IF EXISTS feature?
|
Список | pgsql-hackers |
On Fri, Nov 5, 2010 at 4:48 PM, Daniel Farina <drfarina@acm.org> wrote: > 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. Dan, Can you give us a self-contained example of the problem you're talking about? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: