Posted by: Anonymous Coward
on June 15, 2002 04:29 AM
The PostGreSQL team is better off not promoting PostGreSQL because then people will try it and discover two problems: (i) server crashes, and (ii) corrupted tables.
Until very recently, it was true that MySQL didn't support transactions. However, MySQL very rarely crashed and very rarely had corrupted tables. With PostgreSQL, most potential adopters tried it out, discovered the problems with crashes and data corruption, and then switched to MySQL.
I'd often hear two stories. One of them is that somebody got an app working with MySQL, but he had a pointy-haired boss who told him to use PostgreSQL instead because he believed the FUD about transactions. The other one is that somebody built an app with PostgreSQL, had problems with crashes and corrupted tables, and switched to MySQL. It happened to me twice.
Today, MySQL contains the InnoDB table manager -- a high performance table manager that supports transactions and referential integrity checking. So now, MySQL offers the best of both worlds -- it's reliable (doesn't crash, doesn't get corrupted tables) and it supports transactions. So now there's no room for CrashGreSQL.
Learn about Linux
Download Linux
Get Linux help
No room for CrashGreSQL
Posted by: Anonymous Coward on June 15, 2002 04:29 AMUntil very recently, it was true that MySQL didn't support transactions. However, MySQL very rarely crashed and very rarely had corrupted tables. With PostgreSQL, most potential adopters tried it out, discovered the problems with crashes and data corruption, and then switched to MySQL.
I'd often hear two stories. One of them is that somebody got an app working with MySQL, but he had a pointy-haired boss who told him to use PostgreSQL instead because he believed the FUD about transactions. The other one is that somebody built an app with PostgreSQL, had problems with crashes and corrupted tables, and switched to MySQL. It happened to me twice.
Today, MySQL contains the InnoDB table manager -- a high performance table manager that supports transactions and referential integrity checking. So now, MySQL offers the best of both worlds -- it's reliable (doesn't crash, doesn't get corrupted tables) and it supports transactions. So now there's no room for CrashGreSQL.
#