Re: Extension Packaging
От | Marko Kreen |
---|---|
Тема | Re: Extension Packaging |
Дата | |
Msg-id | BANLkTi=-qmdTji08A+pXJE8SVJeGBMeWTQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Extension Packaging (Daniele Varrazzo <daniele.varrazzo@gmail.com>) |
Ответы |
Re: Extension Packaging
|
Список | pgsql-hackers |
On Thu, Apr 28, 2011 at 4:07 PM, Daniele Varrazzo <daniele.varrazzo@gmail.com> wrote: > On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine > <dimitri@2ndquadrant.fr> wrote: >> Tom Lane <tgl@sss.pgh.pa.us> writes: >>> If you didn't change the install script then it's not necessary to >>> execute ALTER EXTENSION ... UPGRADE. You seem to be assuming that the >>> pg_extensions catalog has to reflect the bug fix level of an extension, >>> but that is *not* the intention. If it did reflect that, you'd need >>> N times as many upgrade scripts, most of them identical, to deal with >>> updating from different bug fix levels of the prior version. >> >> +1 — but this discussion shows we're not exactly finished here. > > Probably what is needed is only a clarification that the version > number is only about schema object, not revision, patch level, release > status or whatever else semantically meaningful. I've attached a patch > for the docs about the point. How about each .so containing a version callback? Thus you can show what is the version of underlying implementation without needing to mess with catalogs just to keep track of patchlevel of C code. -- marko
В списке pgsql-hackers по дате отправления: