Andreas Pflug wrote: > Tom Lane wrote: > >Andrew Dunstan <[EMAIL PROTECTED]> writes: > > > >>However, I don't think we can promise never to change the ondisk > >>representation of data, nor the page layout. Sometimes an inplace > >>upgrade just won't work, ISTM. > > > >We have talked about batching on-disk changes so that they'd only occur > >once every few release cycles. But until we have a pg_upgrade, there is > >no reason to adopt such a policy. > > IMHO such a policy is a _prerequisite_ for somebody to come up > implementing pg_upgrade. Why spend time on pg_upgrade if there's no > policy to support it?
Is anybody working or considering to work on pg_upgrade, or is all this hypothetical? Our past history has seen lots of people offering to work on pg_upgrade, and none has produced a working version. Is it fair or useful to impose restrictions on development just because it's remotely possible that somebody is going to be motivated enough to consider producing it? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
