Re: ALTER EXTENSION UPGRADE, v3
От | Tom Lane |
---|---|
Тема | Re: ALTER EXTENSION UPGRADE, v3 |
Дата | |
Msg-id | 25576.1296756451@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: ALTER EXTENSION UPGRADE, v3 ("David E. Wheeler" <david@kineticode.com>) |
Ответы |
Re: ALTER EXTENSION UPGRADE, v3
Re: ALTER EXTENSION UPGRADE, v3 |
Список | 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 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
В списке pgsql-hackers по дате отправления: