Re: ALTER EXTENSION UPGRADE, v3
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David E. Wheeler" <david@kineticode.com>
Cc: Florian Pflug <fgp@phlo.org>, Dimitri Fontaine <dimitri@2ndQuadrant.fr>, "Ross J. Reedstrom" <reedstrm@rice.edu>, Anssi Kääriäinen <anssi.kaariainen@thl.fi>, Itagaki Takahiro <itagaki.takahiro@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2011-02-03T18:07:31Z
Lists: pgsql-hackers
"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 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