On Fri, Nov 5, 2010 at 4:48 PM, Daniel Farina <drfar...@acm.org> wrote: > On Fri, Nov 5, 2010 at 1:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> Daniel Farina <drfar...@acm.org> writes: >>> On Fri, Nov 5, 2010 at 11:04 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>>> Daniel Farina <drfar...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
