Skip site navigation (1) Skip section navigation (2)

Re: Suggested fix for pg_dump

From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Philip Warner <pjw(at)rhyme(dot)com(dot)au>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Suggested fix for pg_dump
Date: 2001-01-07 18:18:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sun, 7 Jan 2001, Tom Lane wrote:

> The Hermit Hacker <scrappy(at)hub(dot)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' ...

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2001-01-07 18:29:31
Subject: Re: Suggested fix for pg_dump
Previous:From: Tom LaneDate: 2001-01-07 18:18:02
Subject: Re: Re: Beta2 ... ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group