Someone recently tweeted about the fantastic news that MySQL fixed a bug.
Now in my world, bugs get fixed quickly and well. Bugs happen and they need to be fixed. It never occurred to me that we should ever tweet or blog about the fixing of a bug. I guess I assume it’s just quality: bugs get fixed, no drama – people depend upon us to do just that so that the (literally) millions of PostgreSQL servers out there run well. That’s our job and I’m happy and proud to do that job alongside my colleagues at 2ndQuadrant and my colleagues in other PostgreSQL companies and in the wider community.
So the bug in question was “number 199″… check this out
http://lefred.be/content/bye-bye-bug-199/
It’s always been a big argument in the PostgreSQL community about whether we need a bug tracker or not. Obviously, if you fix bugs, why track them? And if you don’t fix bugs, why track them? Hmmm, not sure that’s a hugely rational argument or not, but let’s look at the MySQL bug tracker for bug 199
http://bugs.mysql.com/bug.php?id=199
Yes, that bug was filed 14.5 years ago. And now it’s fixed.
Yay?
Yay? 14.5 years guys! That’s long enough for my pre-school children to have gone to school, grown up and start University. OMG, or if I was crueler, LMFAO.
Maybe its wrong to start a flame war on this, but I need to say, at a personal level, that this is exactly the reason why I have spent years contributing to PostgreSQL and never once contributed to MySQL.
PostgreSQL 10 just came out, if you didn’t hear. I’m certain it will contain bugs, but not that many. I’m also equally certain that we will fix those bugs and that you can rely on the quality and robustness of PostgreSQL.
If you use PostgreSQL in the cloud or from a services company, make sure you ask them what they have contributed to PostgreSQL and what their capability is to fix bugs and with what SLA. The answer to that question is what keeps open source well funded for these latest developments and future ones too.
If you’re interested in learning more about the robustness and security of PostgreSQL, specifically as it applies to enterprise usage – we will be covering that and more at the 2ndQuadrant PostgreSQL Conference in New York (Nov. 7) and Chicago (Nov. 9) – full schedule of topics can be found here or if you’re interested in getting more hands on – we are offering trainings in the following areas in New York on Nov. 6: PostgreSQL Database Security, PostgreSQL-BDR, and PostgreSQL-XL 10.