Re: ALTER EXTENSION UPGRADE, v3
От | Robert Haas |
---|---|
Тема | Re: ALTER EXTENSION UPGRADE, v3 |
Дата | |
Msg-id | AANLkTik5pX33jCdm2W7S7XjTybca-mCcxHba2u2Dzj4U@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: ALTER EXTENSION UPGRADE, v3 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: ALTER EXTENSION UPGRADE, v3
|
Список | pgsql-hackers |
On Fri, Feb 11, 2011 at 3:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes: >> Tom Lane <tgl@sss.pgh.pa.us> writes: >>> However, we're going to have to make a choice for the contrib modules, >>> and I'll bet lunch that most people will follow whatever precedent we >>> set with those. I was thinking about using either "old" or "unpackaged". >>> Thoughts? > >> Will we have to provide different upgrade scripts for different past >> major versions of PostgreSQL? If so, I would say "9.0" or "8.4" would >> be better names. hstore at least is an example that would need this >> treatment I guess. > > I don't foresee us bothering with that. We will only be trying to > upgrade installations that got to 9.1 legitimately. > > I should also make clear that I intend to start out all the contrib > modules at version 1.0. *NOT* 9.1. These things are going to get > version number bumps only when the contents of their install scripts > change, not whenever the surrounding database changes version. If we > number them at 9.1 to start with, it will just promote confusion. What happens if their contents change several times during a major release cycle? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: