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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
