Re: Need concrete "Why Postgres not MySQL" bullet list

Ian's list is excellent.

I would like to add to the point about pl languages.

Use the right tool for the job:
Procedure may be written in tcl, plpgsql, perl,
python, R (statistics) so you can use the right tool
for the job at hand as well as leverage your
existing knowledge of a given scripting language.

It would help to solidify our specific examples
of failures if the version and platform of mysql
is included. Clarifications with postgresql
functionality working correctly may be appropriate
in some cases (also include version & platform).

At oscon, the mysql guys were fighting "old" rumors.
As they glob on functionality to try to catch up
to 1990 technology, they will assert that "we have
transactions now!", etc.

By including the version and platform *and* sticking
only to the facts, we can forstall a few flames.

elein

On Wed, Aug 20, 2003 at 08:39:28AM -0700, Josh Berkus wrote:
> Folks,
>
> I need someone to prepare a standard response for me to send out to inquiries
> on this topic. I get them a lot.
>
> What I'd like is a factual, non-perjorative list of the things which
> PostgreSQL and the PostgreSQL project have that MySQL does not, with a little
> bit of explanation by each. Where links can be provided, please do so.
> Examples:
>
> PROCEDURES: Postgres supports stored procedures (as functions) allowing
> programming in the database for the many tasks which are far more efficient,
> consistent, and secure done there. Procedures may be written in any of nine
> different languages, currently, with two more in development. MySQL does not
> support procedures at all.
>
> TRANSACTIONS: blah, blah, blah. MySQL has just begun offering transactions
> this year, and their solution is largely untested, slow, and suffers from
> complications with the many different "table types". PostgreSQL's MVCC
> transaction support, on the other hand, has been in use in production in
> numerous environments for over six years.
>
> Can anyone do this?
>
> --
> Josh Berkus
> Aglio Database Solutions
> San Francisco
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>