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.0101071417280.21326-100000@thelab.hub.org
Whole thread Raw
In response to Re: Suggested fix for pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses 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:
> > On Sun, 7 Jan 2001, Philip Warner wrote:
> >> Is this OK? Or inappropriate for beta?
>
> > From Tatsuo's example, it looks critical enough that it should be fixed
> > before release, and since its a 'support program' issue, not a 'core
> > server' issue, ramifications of fixing it aren't as big as if it was a
> > 'core server' issue ... go for it
>
> I concur.  This is not a new feature, but a bug fix, and therefore it's
> appropriate to do it during beta.  We don't require beta-period bug
> fixes to be the smallest possible change that cures the problem.  They
> should be good fixes if practical.
>
> One issue however is how confident are we of the alter table add
> constraint code?  I'm not sure it's been exercised enough to justify
> making pg_dump rely on it ... is anyone willing to spend some time
> testing that statement?

Since its obvious that pg_dump isn't working now, we wouldn't be breaking
it any further if the constraint code has a problem with it ... and we
should be able to find out relatively quickly *if* the contraint code has
a problem if its used for something like this ...

Essentially, worst case scenario, we are going from 'broken->broken' ...




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: Beta2 ... ?
Next
From: Tom Lane
Date:
Subject: Re: Suggested fix for pg_dump