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                      
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to