Re: Suggested fix for pg_dump - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: Suggested fix for pg_dump
Date
Msg-id Pine.BSF.4.31.0101071432110.21326-100000@thelab.hub.org
Whole thread Raw
In response to Re: Suggested fix for pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, 7 Jan 2001, Tom Lane wrote:

> The Hermit Hacker <scrappy@hub.org> writes:
> > Essentially, worst case scenario, we are going from 'broken->broken' ...
>
> No, I don't think so.  The current pg_dump code is only broken if
> you've renamed a column involved in a foreign-key dependency (if I
> understood the thread correctly).  But Philip is proposing to change
> pg_dump to rely on alter table add constraint for *all* PRIMARY KEY
> constructs.  So if alter table add constraint fails, it could break
> cases that had nothing to do with either foreign keys or renamed
> columns.
>
> I'm not really arguing not to make the change.  I am saying there's
> an area here that we'd better take care to test during beta cycle...

Agreed ... we almost need a regression test for pg_dump itself :)




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Suggested fix for pg_dump
Next
From: bpalmer
Date:
Subject: Re: CVS regression test failure on OBSD