On Feb 3, 2011, at 9:38 AM, Tom Lane wrote: > Given that pg_upgrade is now considered a supported piece of the system, > ISTM that most real-world upgrade scenarios will be accomplished with > pg_upgrade relying on provision (3). It looks to me like we're talking > about adding a large amount of complication --- both for the core > database and for module authors --- in order to provide a duplicate > solution for that. Why should we bother? Especially, why should we > bother in version 1 of the feature? This could all be added later if > we determine there's really sufficient demand, but right now we have > no experience to show whether there is demand or not.
Given the level of disagreement, I think that leaving upgrades aside for now may be prudent, especially since there are other ways to do it (none very convenient, but no worse than what we have right now, and in the case of pg_dump, better). I think we will need to come back to it before, long, however, because many extensions are released far more often than major versions of PostgreSQL. So while one might run pg_upgrade, at most, about once every 12-18 months, they will often want to take advantage of the features of extensions on a much more ambitious release schedule. Extension upgrades need to be done eventually to make it easier to manage extension release schedules independent of PostgreSQL core upgrades. Otherwise, you're just going to get more patches for contrib. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
