"David E. Wheeler" <david@kineticode.com> writes:
> I think we will need to come back to it before, long, however, because many extensions are released far more often
thanmajor versions of PostgreSQL. So while one might run pg_upgrade, at most, about once every 12-18 months, they will
oftenwant to take advantage of the features of extensions on a much more ambitious release schedule.
Well, pg_upgrade is designed to work within a major-version series, eg
you could do a 9.1-to-9.1 upgrade if you needed to install a newer
version of an extension. Admittedly, this is swinging a rather larger
hammer than "apply an upgrade script" would entail. But I'm still not
convinced that we need to expend a great deal of work on making that
process a tad more efficient.
Now having said that, it does occur to me that there is an upgrade-ish
scenario that every user is going to hit immediately, which is how to
get from an existing installation with a pile of "loose" objects created
by one or more contrib modules to a state where those objects are
understood to be parts of modules. But that is a special case that
perhaps deserves a special-case solution, rather than inventing a very
large wheel.
regards, tom lane