2) PostgreSQL has a better query planner than MySQL.
MySQL's explain works great for me.
Looks nearly identical to the PostgreSQL offering:
I think what the GP was trying to say is that PostgreSQL picks a better execution plan for the query than MySQL does. Not all the time, but certainly some of the time. Several months ago I had both servers setup with the defaults, same schema, same indexes, same dataset, same query. The query was a three table join. Two smaller tables, one with 30,000 rows. PostgreSQL finished almost immediately. MySQL took 3 seconds. It kind of shocked me. I ran explain on both and MySQL simply would not use some of the indexes provided. This was with a 5.0-something release of MySQL. I'd heard that before, but it's still an issue in certain situations.
3) The number value zero in MySQL is treated NULL.
That's a lie.
Glad to know that's fixed! It was true awhile back. So where the issues of inserting data that is too long and having it be silently truncated -- yes, I'm ignoring the warnings MySQL provides. It should raise an error...
I notice that as of 5.0.51a-24 it still turns invalid dates into 0000-00-00 (with the warning, but no error).
5) Until version 5.0, MySQL did not support referential integrity, or
advanced features like views, transactions, or triggers.
This argument is useless. There's a ton of things PostgreSQL used to
not do when it was < 5.0. Replication, binary field storage, etc.
That's not a very fair comparison. Version numbers are meaningless.. Compare the versions at the same time... I will happily agree that prior to 7.x postgres had some issues with these things.
Replication is still not as simple as MySQL's, but there are solutions out there.
I'd suggest we let the original poster do some research on his own and figure out what works best. MySQL vs PostgreSQL is like VI vs Emacs vs TextMate
I don't know how current these pages are, but they are interesting...