Not being sarcastic: this type of article always seems to be written with an audience of "people who love to pick a side and hate the other side, but haven't picked a side yet".
The article picks an extreme example and uses insinuation and condescencion to denigrate MySQL based on one example, but it goes further than that. For example:
> Maybe its wrong to start a flame war on this
So he knows that's what he's doing, and he's okay with that.
> 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.
Maybe, but if I wanted to contribute to Postgres where would I start? There's no bug tracker to look through. With the MySQL family, there is.
Also, I'm willing to bet that most people who've contributed to MySQL haven't contributed to Postgres and vice-versa, so to act as though you're doing it from some kind of principled stance rather than just practicality makes no sense to me.
This entire blog post is a giant attack ad against MySQL for the purpose of making it look bad. "MySQL left a bug unfixed for 14 years while its users' data slowly corrupted. Vote Postgres for RDBMS, and I promise to keep your auto_increment fields consistent, day in and day out."
> Not being sarcastic: this type of article always seems to be written with an audience of "people who love to pick a side and hate the other side, but haven't picked a side yet".
> The article picks an extreme example and uses insinuation and condescencion to denigrate MySQL based on one example, but it goes further than that. For example:
Yeah, I share this opinion. I may agree with some points Simon makes in the blog post, but I certainly dislike how it's presented.
> Maybe, but if I wanted to contribute to Postgres where would I start? There's no bug tracker to look through. With the MySQL family, there is.
I really doubt bug tracker is where people start their contributions. I mean, you don't go to a bug tracker, because (a) if it's broken someone else is probably already working on fixing it, and (b) the unsolved issues are rather complex and not quite suitable for new contributors.
There's actually a bunch of pages on the wiki that might help you:
I'd recommend picking a feature that matters to you and either add it (if it's missing) or improve it in some way. That's how I started contributing - I improved a bunch of stuff in the internal statistics tracking, because I needed that. I improved a bunch of performance regressions, because they were affecting the systems in our production systems. And so on.
Then start talking to people on pgsql-hackers. Send a patch, review patches from other people in the commitfests.
2nd Quadrant is a DBA-as-a-service company that does only Postgres, so it makes sense that the target audience is decision-makers trying to pick between databases who are themselves not DBAs (but probably in the position of hiring DBAs, either as normal employees or as a company to contract with).
FWIW we're not "DBA-as-a-service company". It's part of the job, but we do all sorts of stuff (support, consulting, trainings, custom development, ...)
Postgres is good because we have no open bug tracker whatsoever and we're always adding new features!
I can't figure out who this article is for - certainly not DBAs!