Re: MySQL Compatibility WAS: 8.5 release timetable, again - Mailing list pgsql-hackers
From | Jean-Michel Pouré |
---|---|
Subject | Re: MySQL Compatibility WAS: 8.5 release timetable, again |
Date | |
Msg-id | 1251319460.16259.56.camel@acer Whole thread Raw |
In response to | Re: MySQL Compatibility WAS: 8.5 release timetable, again (Josh Berkus <josh@agliodbs.com>) |
Responses |
Re: MySQL Compatibility WAS: 8.5 release timetable, again
Re: MySQL Compatibility WAS: 8.5 release timetable, again Re: MySQL Compatibility WAS: 8.5 release timetable, again Re: MySQL Compatibility WAS: 8.5 release timetable, again Re: MySQL Compatibility WAS: 8.5 release timetable, again |
List | pgsql-hackers |
> Second, we're not going to support MySQL's *bugs* and *bad design > decisions* which is what lazy developers actually want; they want > something exactly the same as MySQL, including bugs. If they want > that, > they can use MySQL. We are not MySQL, and trying to out-MySQL MySQL > is > stupid, just as it would be to copy Oracle exactly. I understand what you mean. To tell you how lazy MySQL people are is my last experience in the Drupal world. In short, on my devel server, Drupal previous/next link display SQL script returns 21.000 rows. Of course, it should return only two rows. The 21.000 rows are then processed step by step by a PHP script. I open a bug and one of Drupal core developers answers: "Jean-Michel, this is a friendly warning, please change your behavior. This is getting really annoying." In fact, this core developer does not like the way I try to explain how to use databases. I wrote two tutorials: http://drupal.org/node/559302 and http://drupal.org/node/555514 The truth is that Drupal core developers do not believe fixing the prev/next link script is important. They don't care for SQL and don't understand the relationship between SQL queries and CPU cycles. Read this page: http://drupal.org/project/prev_next This performance issue was known for several months and these MySQL developers did not even fixed it. Finally, I escalated to the founder of the Drupal community to ask him to integrate a proper SQL Previous/Next script into Drupal. Their last answer: "Holy crap jmpoure, this is not how the community works. We don't beg to Dries." Read: http://drupal.org/node/559424 > Now, there are things which MySQL does better which we should fix, > because they are real problems for our users who already like > PostgreSQL. These include simple replication, upgrade in place, > driver > maintenance, covering indexes, MERGE, etc. But we'll do these because > they make *Postgres* better, not because MySQL has them. After reading my story, I hope we can agree that noone is going to port any MySQL code to PostgreSQL ever. This demands too much intellectual efforts. Many people will migrate from DB2 and Oracle to PostgreSQL. But no MySQL developer is going to use PostgreSQL if he needs to modify SQL queries. I don't want to be offensive, but I really believe it. So we should support a minimal set of MySQL SQL instructions. After several years of porting MySQL code to PostrgeSQL, I believe that this limited list is enough: http://drupal.org/node/555514 This is quite a straightforward need. Without this list of issues, PostgreSQL may never be able to run popular products developed under MySQL. Think of all commercial and free software projects. The impact of MySQLisms are huge. I can only compare it to Windows vs. GNU/Linux or FreeBSD. This is what comes in mind first. We are not leaving in a perfect world and there no reason to achieve perfectness. So let's support this list, please: http://drupal.org/node/555514 Kind regards, Jean-Michel
pgsql-hackers by date: