Re: Need concrete "Why Postgres not MySQL" bullet list
От | elein |
---|---|
Тема | Re: Need concrete "Why Postgres not MySQL" bullet list |
Дата | |
Msg-id | 20030821111648.B30174@cookie обсуждение исходный текст |
Ответ на | Need concrete "Why Postgres not MySQL" bullet list (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Need concrete "Why Postgres not MySQL" bullet list
|
Список | pgsql-advocacy |
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 >
В списке pgsql-advocacy по дате отправления: