Re: MySQL Compatibility WAS: 8.5 release timetable, again - Mailing list pgsql-hackers

2009/8/26 Jean-Michel Pouré <jm@poure.com>:
> Le mercredi 26 août 2009 à 22:06 +0100, Greg Stark a écrit :
>> That
>> would be unfortunate because I think there are 2 or 3 real
>> improvements hidden in your list.
>
> Then explain I don't have your skills.

What I'm suggesting is that you should take a different direction,
both with Drupal and with us. Instead of saying Postgres is wrong
because of your analysis, ask why what's going wrong and what the
right way to fix it is.  So instead of telling people what to do
you're asking for their help. People are a lot more friendly when
asked for help than when being bossed around.

Your list:

> PostgreSQL and MySQL do not use the same concatenation funtions (D6 only, fixed in D7)

Personally I don't see a problem with us adding this to Postgres now
that we have variadic functions. I'm not sure why others are so
dead-set against it; it seems a lot less burdensome than some of the
Oracle compatibility stuff we have.

> PostgreSQL does CAST implicitely between int and a domain derived from int (unsolved)

This is misdiagnosed. It's not clear where the problem lies if there's
a problem but it likely has nothing to do with the cast. If you posted
with information and asked for help people would suggest things to
test to get more information and eventually find the best way to fix
it.

> PostgreSQL does not allow DELETE on JOINS
> PostgreSQL does not allow UPDATE or DELETE on multiple tables (not solved)

These are a open issues. I would like to have better support here but
it's a major feature, not just a minor compatibility issue. Again if
you posted the queries and asked for suggestions people would help you
rewrite the queries.

> PostgreSQL does not allow mutiple ROW inserts (PostgreSQL 8.2 + only)

As you point out this was added to Postgres 3 years ago

> PostgreSQL does not allow nested ORDER BY

I don't think this is something we're interested in doing. The grammar
is hard enough to maintain as it is.

> PostgreSQL does not automatically cast data between BOOLEAN and INT
> PostgreSQL does not automatically cast data between INT and VARCHAR/CHAR

These are things we've gone out of our way to NOT do. At some cost
too. Being loose here makes it easy to miss errors in your SQL.

> PostgreSQL requires all non-aggregated fields to be present in the GROUP BY clause

As I explained at length we could do something here but it would be a
major feature and it would still not be compatible with MySQL unless
you happen to be using it in a particular (common) way. For more
general uses you have to use DISTINCT ON.

> PostgreSQL requires single quotes and not double-quotes

There's no way in the world we would switch this. We're an SQL engine
and we parse the SQL language which uses quotes in a certain way. If
we switched this we would be parsing some other very different
language and everything else written in SQL (including, say, internal
queries for referential integrity checks or psql tab completion or
pg_dump) would break.

--
greg
http://mit.edu/~gsstark/resume.pdf