"David E. Wheeler" <da...@kineticode.com> writes:
> 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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
