Daniele Varrazzo <daniele.varrazzo@gmail.com> writes:
> On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen <markokr@gmail.com> wrote:
>> 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.
I think what we're discussing here is bug-fix revisions that don't
affect the SQL declarations for the extension. Presumably, that means a
change in the C code, so the shared library is the right place to keep
the revision number. A version number in the control file seems to
carry a nontrivial risk of being out of sync with the actual code in the
shared library.
What's not clear to me is whether to just suggest that extension authors
who care about this should provide a foo_version() function, or to try
to standardize it a bit more than that.
One point worth thinking about is that not all extensions will have
a shared library at all --- SQL-only extensions have been mentioned
several times as an important use case. For those, there's no such
thing as an update that doesn't change the script file, and we shouldn't
try to impose a requirement of providing a lower-level revision number.
regards, tom lane