Re: ALTER EXTENSION ... UPGRADE;
От | Tom Lane |
---|---|
Тема | Re: ALTER EXTENSION ... UPGRADE; |
Дата | |
Msg-id | 2064.1292021011@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: ALTER EXTENSION ... UPGRADE; (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
Josh Berkus <josh@agliodbs.com> writes: > I'd say that for anything in /contrib, it gets a new version with each > major version of postgresql, but not with each minor version. Thus, > say, dblink when 9.1.0 is release would be dblink 9.1-1. If in 9.1.4 we > fix a bug in dblink, then it becomes dblink 9.1-2. > ... > The alternative would be to match postgresql minor version numbering > exactly, and then come up with some way to have a "no-op" upgrade in the > frequent cases where the contrib module isn't changed during a minor > release. This would also require some kind of "upgrade all" command for > contrib. 99% of the time, "fix a bug" just means some C code changes. We should not force DBAs to go through special upgrade commands unless there is some change in the SQL objects created by the extension --- and just as we discourage changes in the SQL objects created by the core during minor releases, we should discourage such changes in minor extension updates. So the case where ALTER EXTENSION UPGRADE is needed will be the exception not the rule. regards, tom lane
В списке pgsql-hackers по дате отправления: