Re: bug report: pg_dump does not use CASCADE in DROP
От | Tom Lane |
---|---|
Тема | Re: bug report: pg_dump does not use CASCADE in DROP |
Дата | |
Msg-id | 5443.1062262457@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: bug report: pg_dump does not use CASCADE in DROP (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: bug report: pg_dump does not use CASCADE in DROP
|
Список | 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 по дате отправления: