Re: MySQL Compatibility WAS: 8.5 release timetable, again

From: Jean-Michel Pouré <jm(at)poure(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: MySQL Compatibility WAS: 8.5 release timetable, again
Date: 2009-08-26 20:44:20
Message-ID: 1251319460.16259.56.camel@acer
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-08-26 20:50:40 Re: MySQL Compatibility WAS: 8.5 release timetable, again
Previous Message Greg Stark 2009-08-26 20:35:38 Re: pretty print viewdefs