Re: bug report: pg_dump does not use CASCADE in DROP - Mailing list pgsql-bugs

From Tom Lane
Subject Re: bug report: pg_dump does not use CASCADE in DROP
Date
Msg-id 5443.1062262457@sss.pgh.pa.us
Whole thread Raw
In response to Re: bug report: pg_dump does not use CASCADE in DROP  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: bug report: pg_dump does not use CASCADE in DROP  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-bugs
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Once pg_dump starts using the dependency information, it seems it could
> do the drops in the proper order, and when it detects
> mutually-dependent tables, it can use a single DROP CASCADE to remove
> them all --- seems like that is a TODO.

You missed my point entirely.  What if DROP CASCADE causes a drop of a
table that did not even exist in the source database, but was added in
the target after the initial data load?  It seems unlikely that that is
desirable behavior for pg_restore.

The correct use of dependency information would be to sort the DROPs
into an order that should succeed *without* CASCADE.  (This will
actually happen for free AIUI, once pg_dump uses dependency info fully.
DROPping in the reverse of a safe creation order should work.)

            regards, tom lane

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: True64 Unix v5.1 - postgresql-7.2.4 compilation problem
Next
From: Bruce Momjian
Date:
Subject: Re: bug report: pg_dump does not use CASCADE in DROP