Re: bug report: pg_dump does not use CASCADE in DROP - Mailing list pgsql-bugs
From | Bruce Momjian |
---|---|
Subject | Re: bug report: pg_dump does not use CASCADE in DROP |
Date | |
Msg-id | 200308301557.h7UFvh508644@candle.pha.pa.us Whole thread Raw |
In response to | bug report: pg_dump does not use CASCADE in DROP (Preston Landers <planders@journyx.com>) |
Responses |
Re: bug report: pg_dump does not use CASCADE in DROP
(Tom Lane <tgl@sss.pgh.pa.us>)
|
List | pgsql-bugs |
This is a tough one. The CASCADE shouldn't be needed because the clean should be done in an ordering so that dependency is honored. Of course, that doesn't fix problems with mutually-dependent tables. Should we be using CASCADE? Seems that is going to double-drop some tables. --------------------------------------------------------------------------- Preston Landers wrote: > ============================================================================ > POSTGRESQL BUG REPORT TEMPLATE > ============================================================================ > > > Your name : Preston Landers > Your email address : planders@journyx.com > > > System Configuration > --------------------- > Architecture (example: Intel Pentium) : > Intel Pentium II 500mhz (dual CPU) > > Operating System (example: Linux 2.0.26 ELF) : > Linux 2.4.2-2smp (Redhat 7.1) > > PostgreSQL version (example: PostgreSQL-7.3): > PostgreSQL-7.4beta2 snapshot (from 2003/8/26.) > > Compiler used (example: gcc 2.95.2) : > GCC 2.96 > > > Please enter a FULL description of your problem: > ------------------------------------------------ > > I'm not sure if this is a bug report, feature request, or evidence of my > infirmity, but here it goes: > > pg_dump from 7.3+ does not use the CASCADE in the DROP statements (when > the -c clean option is used.) > > This is a problem when you are trying to restore the dump back onto > the same site and tables already exist, or perhaps this is just an error > in my understanding of how you perform Postgresql backup and restores. > > > > Please describe a way to repeat the problem. Please try to provide a > concise reproducible example, if at all possible: > ---------------------------------------------------------------------- > > Do a pg_dump -c. Restore it back to the same site. The tables will > not be dropped if they have FK constraints or any other dependencies, > resulting in an incorrect restore. > > > If you know how this problem might be fixed, list the solution below: > --------------------------------------------------------------------- > > Simply include the CASCADE option on all DROP TABLE, INDEX, VIEW, and > TRIGGER statements. If you feel this is too dangerous, at least > provide it as a command-line option to pg_dump, so people don't have > to hand-edit their dump files to be able to restore them. > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073
pgsql-bugs by date: