Re: Extension Packaging - Mailing list pgsql-hackers

On Thu, Apr 28, 2011 at 4:40 PM, Daniele Varrazzo
<daniele.varrazzo@gmail.com> wrote:
> On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen <markokr@gmail.com> wrote:
>> 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.
>
> On this line, it would be easier to add a parameter "revision" to the
> control file and have a function pg_revision(ext) to return it,
> eventually showing in the \dx output. But this still assumes the
> revision as being just a string, and if it has a semantic meaning then
> it requires parsing to extract meaning for it (whereas foo_revision()
> may return everything the author of foo thinks is important for code
> depending on it to know, e.g. it may return an integer 90102 or a
> record (major, minor, patch, status, svn-rev,
> name-of-my-last-daughter). I don't think we want to force any
> convention, such as the revision being a semver number - even if PGXN
> restrict the extension to this strings subset.

Yeah, I was thinking about such convertionless patchlevel,
just for information.  Authors would use it for patchlevel,
but packages could put their version numbers there too.

Main idea would be to see the noise versions also in db,
otherwise you still need to go to OS to see whats actually
installed.

Reading it from control file seems even better solution for that,
although there is minor problem of running backend
using older .so-s than installed.  But that does not seem serious
enough to warrant a workaround.

--
marko