Extensions Dependency Checking

Hackers,

I wanted to get a (ok, not so) quick note in about this before the beta dropped. I've been thinking about the
"requires"parameter on extensions control files. Right now it just lists the names of extensions that are required for
theextension to run: 
   requires = 'foo, bar'

But I'm assuming that at some point there's going to be something a bit more robust: specifically, requiring a minimum
version,perhaps something like: 
   requires = 'foo 1.0, bar 0.31.4'

I know that Dimitri has thought about this a bit, and I suspect we can all agree that most extensible systems have some
wayto at least specify the minimum version of a dependency. Is this something that's likely to come down the pike,
perhapsin 9.2 or later? 

If so, we return to the issue of comparing version strings in order to resolve/verify dependencies.

One way to solve the problem would be either for a developer to specify a version order in the control file, or else to
ensurethat the upgrade scripts are there for every single version. 

But frankly, I would oppose something like this, as it once again puts the onus on the extension developer to take care
ofwhat is essentially a bookkeeping detail. And if I'm any example, there will often be mistakes, typos, etc. 

I think a better solution would be to mandate a version string format for extensions *today*. This would remove the
onuson the developer, while making version comparisons inside the database efficient and predictable. 

Now, I know that ideas has been rejected in the past (at least for *right now*), but I'm here to tell you that not
solvingthis problem up front is fodder for a nightmare later. Perl, for example, has only recently standardized on a
versionnumbering scheme, but thanks to a 15 year history of none at all, it has to bend over backwards to try to manage
anyversion scheme in existence. I mean, just look at this mess: 
 http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/

I definitely think that version numbers should be boring. A few simple rules and then forget about it, it should just
work.

I certainly didn't want to deal with this issue in PGXN, where dependency checking is planned for the command-line
client.So I decided to use semantic versions. They have now been implemented as a native type in PostgreSQL, thanks to
SamVilain porting the PL/pgSQL-based domain I originally wrote. The code is here: 
 http://master.pgxn.org/dist/semver/0.2.0/

The reason I went with semantic versions, rather than just a numeric, as I'd originally planned, is because they are
almostexactly the same format as PostgreSQL version numbers. So they were useful for specifying a dependency on a
particularversion of PostgreSQL. So by letting the core project set the standard, with just a minor modification of
thatstandard, I get something that just works but is much more flexible than a numeric version. FWIW, the only
differencethat I've noticed between semantic versions and PostgreSQL versions is in developer/alpha/beta releases. So
wherePostgreSQL has released 9.1alpha5, the semantic version is 9.1.0alpha5. (And the semver data type can convert from
theformer to the latter). 

So, to summarize:

* I think we're going to need a formal version string spec for extensions.

* If that's true, I think it should be specified *now*, before extensions are in the wild, so that we don't end up with
thelegacy version string nightmares that Perl modules suffer from. 

* If we do adopt a spec, I think it should reflect the PostgreSQL core version strings as closely as possible, and
shouldbe fully compatible with them. 

* So it might be worth looking at semver or something similar to integrate.

Thoughts?

Best,

David