Re: Suggested fix for pg_dump
От | The Hermit Hacker |
---|---|
Тема | Re: Suggested fix for pg_dump |
Дата | |
Msg-id | Pine.BSF.4.31.0101071417280.21326-100000@thelab.hub.org обсуждение исходный текст |
Ответ на | Re: Suggested fix for pg_dump (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Suggested fix for pg_dump
|
Список | 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 по дате отправления: