What's in a version number?

The other day I came across yet another company (who shall remain nameless, but are certainly not alone) who support using PostgreSQL as a backend for their product. And the support only version 8.2.3. While I prefer using 8.3 on all production servers today, I find it perfectly normal and acceptable that they don't support that, and only 8.2. What is not acceptable to me is only supporting 8.2.3. The 8.2 branch is currently at 8.2.11, and there are several critical bugs - including security issues - patched in these versions. I would not recommend any customer of mine to use 8.2.3 today.

So why is this? The only reason I can think of is that these company simply haven't bothered to figure out how the version numbering of the products actually works. For those who don't know, a quick intro to the PostgreSQL system: * Major versions are 8.0, 8.1, 8.2, 8.3 (no, you cannot reasonably claim to support "PostgreSQL version 8", which is also not uncommon, because that includes potentially incompatible future version) * Minor versions are 8.2.1, 8.2.2, 8.2.3 etc. * Minor versions contain only critical fixes. There are never new features introduced. There are almost never any kind of incompatible changes introduced (I say almost never, because it has happened when required to plug a security issue)

This should make it fairly obvious that it is counterproductive to support only 8.2.3. Because you are basically forcing the customers not to apply critical security fixes.

The fact that different databases follow different patterns here obviously makes it a little bit harder for the vendor. For example, it would not make sense to say you support MySQL 5.1. Because that can include both beta and release candidate versions. And they do regularly introduce new features and change behavior between versions like 5.1.x and 5.1.y. That's just how their numbering works. I don't personally like that way of numbering releases, but if I was putting out a product saying which versions of MySQL I support, I'd certainly read up on exactly how the version numbers work first.

If you cannot take the time to figure out how the release process of your database product works, why does it matter that you put in the version number at all? It's not likely it's properly supported anyway. That statement should be about "once tested with version x", not actually supported...

And to finish off: what I'd like to see is "we support version 8.2 starting at version 8.2.3" for example. That clearly identifies which major release is supported (8.2). And it also indicates that vendor takes it upon themselves to make sure their product continue working if the customer applies relevant security patches (AKA minor releases).

Ok, that's enough ranting for today...

On the topic of release quality

This post was inspired by Montys post about MySQL release 5.1, and the many discussions it has created both around the web and offline. The question mainly being - why has nobody made such a post about PostgreSQL yet? Is it because it hasn't happened, or just because nobody has posted about it.

We all know that there is no such thing as bug-free software. This obviously includes both PostgreSQL and MySQL, as well as all the commercial competitors - claiming anything else is clearly untrue. But what I find remarkable from Montys post are mainly:

• MySQL 5.1 has been released with known critical bugs (crash/wrong result). As far as I know, this has never been done with PostgreSQL (at least if we're talking "modern times", since after the product became reasonably stable). And certainly not the number of issues that Monty has listed for MySQL 5.1 - it's not just one or two!
• There are also critical bugs that were present in 5.0, that still haven't been fixed in 5.1.
• We already know that MySQL 5.0 was released "too early". We already know that MySQL 5.1 was declared RC "too early". It's remarkable that 5.1 was also released "too early" in that case - and for non-technical reasons again. In theory, this "can't happen" with the PostgreSQL release model, since it's based only on when the features are "ready", not when you need a new release for some other reasons. That's in theory. I know in the past we have tried to schedule releases around certain conferences and such, for better announcement effects. In practice, though, I think this has only led to a release being postponed, never being rushed.
• MySQL apparantly keep some bug reports hidden from the public (the referenced bug 37936 for example). How's that for open... I approve of keeping them hidden for security bugs only - but if that bug is a security bug, it's clearly taken way too long to fix, given the dates on bugs around it.
• I still think they've designed their version numbering system to deliberately confuse the customers about what is a beta, what is a release candidate and what is a release. What is so easy with either labeling them as PostgreSQL does (8.3beta, 8.3RC, 8.3.0), or using the in open source popular system of using even-numbered releases for stable releases and odd numbers for beta/testing releases?
• It took them over a year to get from Release Candidate to release.

Now, there are several posts I found that are questioning Montys post, saying that the quality is just fine - and backing this up with actual experiences in deploying 5.1. I do think both sides are right here - it's perfectly possible to deploy 5.1 without hitting these bugs, as they are "corner-case" issues. But that does not decrease the importance of having releases without known bugs in them. And if there are known bugs, they should at least be listed very clearly in the release notes/announcement. Not doing this is, IMHO, simply irresponsible. Especially least for a database server which is supposed to safeguard all your work...

So how does PostgreSQL measure up

Continue reading

A new MySQL gotcha

At least it's new for me, and it's not on the list. Bugged a colleague of mine today, and we were both very surprised for a while until we figured it out. Ok, it's not very complex, but the deal was that:

SELECT CAST(1 as CHAR)

works, but

SELECT CAST (1 as CHAR)

does not (syntax error!)

Now, CAST is already horribly limited in MySQL (who came up with the idea that you shouldn't be able to cast to all available types if it's reasonable to do the conversion?! Like from int to text...), but this is just too much. Since when does whitespace before a parenthesis matter in SQL?! Sheesh...

Yet another reason to prefer PostgreSQL...

Not quite open source

I found a couple of posts over on Planet MySQL today about some new announcement from the dolphin-herders. Apparantly, the Sun/MySQL combination is now starting to push at least some features for Enterprise customers only. AFAIK this isn't entirely new, since they've had some tools previously only available to enterprise customers, but I guess this would be a first for actual server code. (Though the way patches are moved between Enterprise and Community never really made sense to me, that's probably because I didn't study it in enough detail)

From what I can tell, this puts MySQL more towards the situation that PostgreSQL has with EnterpriseDB (and their now renamed product Postgres Plus Advanced Server) and some other companies. This is a proprietary product that sits on top of an open source foundation that is PostgreSQL. Now, EnterpriseDB initially marketed this product as opensource - which was incorrect, and they got quite a bit of bad press about it. The question is, what will Sun/MySQL do now. Will they continue to market their Enterprise product as Open Source, which it obviously isn't, or will they change that?

It is also interesting to note that this would not be possible if MySQL was licensed as pure GPL. With the current model, this is only possible for Sun/MySQL to do, and no other company. Unlike PostgreSQL which is BSD licensed, and allows any company to create this kind of proprietary derived product. If I was a contributor to MySQL (which I'm not), I would consider this quite unfair. But that's what you get with the dual licensing model used by MySQL, and this is why contributors have to sign away their rights to Sun/MySQL. It's not surprising to me that this happens, and it's one of the reasons I haven't liked the MySQL licensing model from the start. The other side of the coin would be a pure GPL license, which would not allow anybody at all to create a proprietary derived product - but that's a whole different debate to take on...

So is this a dealbreaker? Well, I don't know exactly which features they are talking about in this case (since I'm not a Sun/MySQL partner), but there was talk of it being things around backups. IMHO, such extremely core functionality really should be in the main product - which is how PostgreSQL has it today. But more importantly, if this is the new path Sun/MySQL is going to be heading down with their products, I can see how that will be a problem for a number of their customers.

And if you're one of them - you're always welcome to cross over and join us over here by the elephant...