On Thu, Apr 28, 2011 at 3:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Daniele Varrazzo <daniele.varra...@gmail.com> writes: >> On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen <mark...@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.
There is also the case of extensions whose data file matter: for instance I've packaged the Italian text search dictionary as an extension (http://pgxn.org/dist/italian_fts/): it contains no .so but it may happen for the dictionary files to be changed. Its version is 1.2 and will stay so as long as the sql doesn't change, but its revision is currently 1.2.1 and may bump to 1.2.2 should the dict content change. For this extension, just spotting the 1.2.1 in the \dx output would be more than enough, I don't see any use for the revision number returned in an api call. As long as the extension is installed via "make install" the .control shouldn't drift away from the extension files it represents. -- Daniele -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
