Re: bug report: pg_dump does not use CASCADE in DROP

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Preston Landers <planders(at)journyx(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: bug report: pg_dump does not use CASCADE in DROP
Date: 2003-08-30 16:54:17
Message-ID: 5443.1062262457@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2003-08-30 17:28:40 Re: bug report: pg_dump does not use CASCADE in DROP
Previous Message Bruce Momjian 2003-08-30 16:51:43 Re: True64 Unix v5.1 - postgresql-7.2.4 compilation problem