A few bugs/limitations of Mysql not shared by Postgres. All AFAIK.
* Integer columns with null constraints will silently translate nulls to 0s, rather than throwing an error (as constraints in all other contexts do). Imagine a database which, on violation of a foreign key constraint, just silently picked the first row in the target table - it's just insane.
* Transactions can't roll back schema changes, so if you have a Rails migration which fails on the application of a unique index in the midst of other operations, too bad. Your DB is stuck in the no-mans-land between migrations.
* Constraints are anemic relative to postgres: no integer range or string length constraints, no whitelist, blacklist, regex match, &c. &c.
There are certainly others I've run into, but the above indicate to me that the Postgres developers are working with/delivering a better code-base.
That's a feature of postgres rather than a limitation of mysql however. As far as I know the SQL Standard doesn't ask for transactional DDL, Oracle has pretty much no support for transactional DDL (in 10g anyway, each DDL statement is executed in its own transaction and any pending transaction is COMMITted before a DDL), I have no idea about SQL Server.
(and don't get me wrong, it's a totally awesome feature and it should be praised to high heaven, but it's an additional feature nonetheless, rather than a limitation of the concurrence)
MSSQL supports it because it was inherited from Sybase. SQLite also supports it as well. You're right that it's a feature, but frankly I can't live without it -- there's no way to write safe schema migrations!
* Integer columns with null constraints will silently translate nulls to 0s, rather than throwing an error (as constraints in all other contexts do). Imagine a database which, on violation of a foreign key constraint, just silently picked the first row in the target table - it's just insane.
* Transactions can't roll back schema changes, so if you have a Rails migration which fails on the application of a unique index in the midst of other operations, too bad. Your DB is stuck in the no-mans-land between migrations.
* Constraints are anemic relative to postgres: no integer range or string length constraints, no whitelist, blacklist, regex match, &c. &c.
There are certainly others I've run into, but the above indicate to me that the Postgres developers are working with/delivering a better code-base.