Andreas Pflug wrote:
> Tom Lane wrote:
> >Andrew Dunstan <andrew@dunslane.net> 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
