In MySQL, you can set the SQL mode to make it just as strict as Postgres. I'm still using MySQL for two reasons: a) It's already in place and it works great and b) I'm very familiar with it. For the next project (which may never come), I'll definitely be looking into Postgres.
In MySQL, you can set the SQL mode to make it just as strict as Postgres.
How much are you inclined to trust this mode which was bolted on as an afterthought, though?
I'm maintaining a bunch of MySQL installs for customers and the amount of random failures I've seen even with InnoDB and strict mode during backup/restore and upgrades is just not funny.
Obscure second guesses during even a minor version upgrade are the rule rather than the exception. 'mysql_upgrade' hardly ever worked right for me at first try. A straightforward dump/restore is not an option either because they change the schema of the system tables all the time (which, to add insult to injury, are still MyISAM).
Then you also frequently bump into gems like the following:
Incompatible change: As of MySQL 5.5.3, the server includes dtoa, a library for conversion between strings and numbers by David M. Gay. In MySQL, this library provides the basis for improved conversion between string or DECIMAL values and approximate-value (FLOAT/DOUBLE) numbers.
Because the conversions produced by this library differ in some cases from previous results, the potential exists for incompatibilities in applications that rely on previous results. For example, applications that depend on a specific exact result from previous conversions might need adjustment to accommodate additional precision.
(From: http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previo...)
Oh, and don't get me started on what they call "replication", which will happily, silently desync or corrupt data in various situations.
So well, yeah. Perhaps strict mode indeed works right in all cases. Perhaps.
Comments
In MySQL, you can set the SQL mode to make it just as strict as Postgres. I'm still using MySQL for two reasons: a) It's already in place and it works great and b) I'm very familiar with it. For the next project (which may never come), I'll definitely be looking into Postgres.
In MySQL, you can set the SQL mode to make it just as strict as Postgres.
How much are you inclined to trust this mode which was bolted on as an afterthought, though?
I'm maintaining a bunch of MySQL installs for customers and the amount of random failures I've seen even with InnoDB and strict mode during backup/restore and upgrades is just not funny.
Obscure second guesses during even a minor version upgrade are the rule rather than the exception. 'mysql_upgrade' hardly ever worked right for me at first try. A straightforward dump/restore is not an option either because they change the schema of the system tables all the time (which, to add insult to injury, are still MyISAM).
Then you also frequently bump into gems like the following:
Incompatible change: As of MySQL 5.5.3, the server includes dtoa, a library for conversion between strings and numbers by David M. Gay. In MySQL, this library provides the basis for improved conversion between string or DECIMAL values and approximate-value (FLOAT/DOUBLE) numbers.
Because the conversions produced by this library differ in some cases from previous results, the potential exists for incompatibilities in applications that rely on previous results. For example, applications that depend on a specific exact result from previous conversions might need adjustment to accommodate additional precision. (From: http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previo...)
Oh, and don't get me started on what they call "replication", which will happily, silently desync or corrupt data in various situations.
So well, yeah. Perhaps strict mode indeed works right in all cases. Perhaps.