You say that MySQL has solved problems but you won't count it because it's not the default? The reason it's not the default is that people expect to be able to upgrade from older versions without having to change their code. I think this is a fair expectation.

If your node was named "Why I will use InnoDB tables and strict SQL mode for all new projects" it would make just as much sense. There is no reason to start a new project with MyISAM tables and the old SQL mode. InnoDB with foreign keys and transactions has been production ready for 7 years now!

You say that MySQL has solved problems but you won't count it because it's not the default?

No, I say that solutions of these problems aren't as valuable as they could be if they were default.

Discovering glitches and then finding that they have already been solved but that I didn't know about these solutions, always leaves that nasty feeling that I'll come across more of those.

Sane defaults are important. Very much so. The Postgres 8.2 manual has about 1700 pages (A4), I'd expect mysql to have about as much documentation. You can be sure that I won't read them all before starting to use my db engine. If the defaults can easily hurt me, I'm lost.

The reason it's not the default is that people expect to be able to upgrade from older versions without having to change their code. I think this is a fair expectation.

Yes and no. Backwards compatibility is valuable, but it shouldn't be the first ruling principle. When our notion changes of what is sane and what not, we sometimes have to break something. Perl does that from time to time as well.

If you really care about compatibility, you can define a set of options that can be activated with a special variable or flag, some kind of a compatibility level.

Update: consider an analogy: if you had the choice between two programming languages, one being perl, and the other being strictperl, that is perl with use strict; use warnings; enabled by default - which one would you use? I'd stick with perl for my old scripts that aren't strict safe, and chose the strictperl version for everything that I newly write.

One problem with the "strict mode" solution is it's set on the client. It means you have to be careful about what clients access the DB, or one misbehaving tool could ruin it for everyone. Altho the improvements are what we've all been asking for, they kind of feel "bolted on", whereas they were fundamental design goals of Postgres from the beginning.

Ultimately, both are good choices though. Open source is about giving us more choice, not less. I think the only thing is some people see the success of MySQL as disproportionate to it's quality, when compared to Postgres. (But maybe it's just an example of "worse is better").

It can be changed on the client, but the default is set on the server. Someone would have to intentionally change it in order to have this problem. If a malicious user has access to your database, changing the SQL mode is the least of your worries.

It still means you have to be wary about who/what you give access to the DB. For some (most?) apps you'd do that anyway, but others might benefit from a more open policy. What if someone has a legacy app build for 4.x ... the quickest way to get it working is just to set the mode to "traditional". It might be a minor thing, but it's something you simply won't have to worry about with Postgres. (Unless there's a way to disable a mode completely on the server, in which case ignore me :)

I agree fully with this node. I love Postgres, and it is most certainly better than Inno for many reasons. But, these stupid posts fail to acknowledge anything MySQL has done right and instead they cherry pick the most-wrong way to do something and present it in such a biased fashion that Bill O'reilly would cry blood. If you want to compare apples with apples, compare the *newest* version of Postgres (8.3) with the *newest* version of MySQL and ignore the non-inno backends. It does surprisingly well.
Pg still has so much room for improvement, and it certainly isn't the easiest of the two to develop in. Though I would have to say, I've seen MySQLs "user variables" abused to do some pretty simple tasks that can be done with a simple Pg aggregate.

If you want to compare apples with apples, compare the *newest* version of Postgres (8.3) with the *newest* version of MySQL

Cool idea. Why not get to work on it? Myself, I'd love to spend the next year working on database benchmarks and reliability tests just so I can have an informed opinion in a geek debate. Of course, no one will actually pay any attention to you, and by the time you're done the databases you're studying will have changed some more, but what the hell.

and ignore the non-inno backends.

You mean, pretend that most people aren't using the default?

It does surprisingly well.

Ah, so you do have some data? You've compared the results with both databases, then? What was surprising about your results?

Pg still has so much room for improvement, and it certainly isn't the easiest of the two to develop in.

And where would that "room for improvement" be, precisely?
I can't imagine why you'd find it harder to develop for than any other database.

(Department of cheap irony: perlmonks.org hit a "database error" when I first tried to post this.)

Inno is the default for a backend *that requires transactions* and has been for a while. The assumption is simply that the most typical use of database will not require transactions -- which is probably true if you follow the mindset that a hash functions better as an api into a database. And, if your argument is on the lines of being informed costs too much time.. then just do us all a favor and remain silent.

MySQL has a pseudo-SQL interface into the DB which is more uniform for a new user. I'm also told from people that use MySQL replication that it is easier to manage -- and it works off the shelf without having to install a contrib module. MySQL still has more functionality in the CSV libraries. And, MySQL supported fts (without contrib modules) before pg. There are a ton of other things, like "AUTO INCREMENT" makes more sense than "serial" -- and if you give write access to a table in Postgres you assume you can insert into, but not if it has a serial datatype, because that creates a index. An Index is incremented on the write, therefore the index too has to be +w.

MySQL supports SQL extensions for mere convenience which Pg has a higher resistance to permitting. See "INSERT ignore INTO ...", "ON DUPLICATE KEY UPDATE", and

Went to join the gridlock to see it
Held an eclipse party
Watched a live feed
I cn"t see tge kwubosd to amswr thus
I tried to see it, but 8000 miles of rock got in the way
What eclipse?
Wanted to see it, but they wouldn't reschedule it
Read the book instead