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 the extension 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 way to at least specify the minimum version of a dependency. Is this something that's likely to come down the pike, perhaps in 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 ensure that 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 of what 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 onus on 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 solving this problem up front is fodder for a nightmare later. Perl, for example, has only recently standardized on a version numbering scheme, but thanks to a 15 year history of none at all, it has to bend over backwards to try to manage any version 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 Sam Vilain 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 almost exactly the same format as PostgreSQL version numbers. So they were useful for specifying a dependency on a particular version of PostgreSQL. So by letting the core project set the standard, with just a minor modification of that standard, I get something that just works but is much more flexible than a numeric version. FWIW, the only difference that I've noticed between semantic versions and PostgreSQL versions is in developer/alpha/beta releases. So where PostgreSQL has released 9.1alpha5, the semantic version is 9.1.0alpha5. (And the semver data type can convert from the former 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 the legacy 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 should be fully compatible with them.

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

Thoughts?

Best,

David