Re: Upgrading a database dump/restore
От | Mark Woodward |
---|---|
Тема | Re: Upgrading a database dump/restore |
Дата | |
Msg-id | 21593.24.91.171.78.1160365456.squirrel@mail.mohawksoft.com обсуждение исходный текст |
Ответ на | Re: Upgrading a database dump/restore (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Upgrading a database dump/restore
|
Список | pgsql-hackers |
> "Mark Woodward" <pgsql@mohawksoft.com> writes: >> Not to cause any arguments, but this is sort a standard discussion that >> gets brought up periodically and I was wondering if there has been any >> "softening" of the attitudes against an "in place" upgrade, or movement >> to >> not having to dump and restore for upgrades. > > Whenever someone actually writes a pg_upgrade, we'll institute a policy > to restrict changes it can't handle. But until we have a credible > upgrade tool it's pointless to make any such restriction. ("Credible" > means "able to handle system catalog restructurings", IMHO --- without > that, you'd not have any improvement over the current rules for minor > releases.) IMHO, *before* any such tool *can* be written, a set of rules must be enacted regulating catalog changes. If there are no rules and no process by which changes get approved, requiring a "was is" conversion strategy, then the tools has to change with every major version, which will, of course, put it at risk of losing support in the long term. Like I said, I understand the reluctance to do these things, it isn't an easy thing to do. Designing and planning for the future is, however, the hallmark of a good engineer.
В списке pgsql-hackers по дате отправления: