On Thu, Apr 28, 2011 at 2:21 PM, Marko Kreen <mark...@gmail.com> wrote: > On Thu, Apr 28, 2011 at 4:07 PM, Daniele Varrazzo > <daniele.varra...@gmail.com> wrote: >> On Wed, Apr 27, 2011 at 1:48 PM, Dimitri Fontaine >> <dimi...@2ndquadrant.fr> wrote: >>> Tom Lane <t...@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. -- Daniele -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
