This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: pgsql-advocacy-postgresql.org@localhost.postgresql.org
From: Ian Barwick <barwick@gmx.net>
Subject: [pgsql-advocacy] PostgreSQL <> MySQL: first draft
Date: Mon, 15 Sep 2003 01:12:38 +0200
Attached are two text files:
pgsql_mysql.txt
- an annotated list of PostgreSQL features not available in MySQL;
pgsql_mysql-short.txt
- a condensed version of the above.
The document covers the major differences, though it is not
exhaustive (and full of spleling errors). Corrections, suggestions for
improvement gratefuly received. Or if someone wants to wikify it or,
whatever, fine by me ;-). I've tried to make it readble, i.e. something
to show the technically-aware PHB.
I will be away from tomorrow and though I will have Internet access
I might not have time to read the mailing list for a week or so.
It's taken me longer than I though due to other committments and partly
because of the level of involvment, I keep getting sidetracked by
interesting things in the documentation.
One area where I haven't had time to go into any detail is
MySQL's transaction model. Of particular interest would be
why it just took a MySQL InnoDB table nearly 30 minutes to
rollback about 270,000 insertions when PostgreSQL did it
almost instantly.
On a related note: since I posted the link to the MySQL gotchas
the site has unexpectedly found its way into Google and about
half the hits are from people who've pasted their MySQL error
message into the search field; and I also got a mail from MySQL
in Germany saying how well researched it is and they had comments
on three of the points which I've addressed in various ways.
[1. text/plain; pgsql_mysql.txt]
PostgreSQL features not present in MySQL
========================================
Cursors
-------
Cursors enable clients to control the number of result rows
returned from the database by stepping through the result set
in user-defined intervals. This is particularly useful
when manipulating large result sets.
- MySQL has no support for cursors. Implementation
is planned at an unspecified future date:
http://www.mysql.com/doc/en/TODO_MySQL_5.0.html
- PostgreSQL offer advanced cursor support as part of its core
functionality. Cursor support has been available since at
least version 6.4:
http://www.postgresql.org/docs/6.4/static/sql-declare.htm
External functions
------------------
Specialized applications may require features not part of a
database's core functionality but which rely on direct interaction
with the database engine and cannot be implemented using stored
procedures. This requires the ability to directly extend a database
system with external functions.
- MySQL has only rudimentary and undocumented support for external
functions written in the C language:
http://www.mysql.com/doc/en/Writing_a_procedure.html
- PostgreSQL supports creation of external functions in C and C++
as well as user-defined datatypes, operators and aggregates.
Many mature third-party extensions to PostgreSQL's core functionality
have been created using this feature:
http://www.postgresql.org/docs/current/static/extend.html
Sequences
---------
Databases often require the generation of values in sequential
order, e.g. to provide unique values for a table's primary key.
- MySQL provided only a very basic sequence generator called
"AUTO_INCREMENT". There can only be one AUTO_INCREMENT per table
and it can only be used on primary key columns. AUTO_INCREMENT
can only generate values in increments of 1 (negative increments
are not supported). There is no provision for warpround once the
sequence hits the column's maximum value. See:
http://www.mysql.com/doc/en/example-AUTO_INCREMENT.html
As AUTO_INCREMENT is implemented as SELECT MAX(col) FROM table,
it makes transactions prone to deadlocks:
http://www.mysql.com/doc/en/InnoDB_auto-increment_column.html
- PostgreSQL provides flexible sequence support which can generate
values in user-defined increments (both ascending and descending)
between specified minimum and maximum values. PostgreSQL sequences
do not cause deadlocking in transactions:
http://www.postgresql.org/docs/current/static/sql-createsequence.html
Stored Procedures
-----------------
Stored procedures are blocks of code stored and executed in
the database backend. They are typically created in an SQL-like procedural
language or a fourth-generation language such as Java or Perl.
- MySQL has no support for any form of stored procedure. Implementation
is planned at an unspecified future date:
http://www.mysql.com/doc/en/ANSI_diff_Triggers.html
- PostgreSQL provides mature and tested support for function creation
in SQL and the following procedural languages:
PL/PgSQL (PostgreSQL's own procedural language, similar
to e.g. Oracle's PL/SQL)
Perl
Python
Tcl
http://www.postgresql.org/docs/current/static/programmer-pl.html
An implementation of PHP as a procedural language is currently
under development.
http://www.commandprompt.com/entry.lxp?lxpe=260
External functions can also be written in C or C++:
http://www.postgresql.org/docs/current/static/xfunc-c.html
System Catalog
--------------
A system catalog (also known as a "data dictionary") stores
meta-information about a database as normal tables and views.
This enables a DBA to gain information about database operations
and possibly manipulate global database settings.
- MySQL does not have a system catalog, although it does provide
a seperate "mysql" database for manipulating database user permissions.
- PostgreSQL has a system catalog as part of its core functionality:
http://www.postgresql.org/docs/current/static/catalogs.html
Beginning with version 7.4 it will also provide database meta-information
via the standardized "information_schema" defined in SQL-92:
http://developer.postgresql.org/docs/postgres/information-schema.html
Triggers
--------
Triggers are units of code stored in the database which are
executed when certain actions are carried out. They automate
many routine tasks and can be used to enfore data integrity
and business rules.
- MySQL does not support triggers. Implementation
is planned at an unspecified future date.
http://www.mysql.com/doc/en/ANSI_diff_Triggers.html
- PostgreSQL supports triggers (and a related facility called 'rules')
as part of its core functionality. PostgreSQL triggers
can be written in any supported procedural language:
http://www.postgresql.org/docs/current/static/sql-createtrigger.html
http://www.postgresql.org/docs/current/static/sql-createrule.html
PostgreSQL has supported triggers since at least version 6.3:
http://www.postgresql.org/docs/6.3/static/c38.htm
Views
-----
VIEWs are an important element of efficient professional database design,
pushing repetitive, often duplicated queries into the backend,
increasing the flexibility of an application and reducing the risk of errors.
They also enable the encapsulation of table structure, which may change
with application development, behind a consistent interface.
- MySQL does not support views. Implementation is planned at an
unspecified future date:
http://www.mysql.com/doc/en/ANSI_diff_Views.html
- PostgreSQL supports views as part of its core functionality:
http://www.postgresql.org/docs/current/static/sql-createview.html
PostgreSQL has supported views since at least version 6.4:
http://www.postgresql.org/docs/6.4/static/sql-createview.htm
Features present in PostgreSQL and MySQL
========================================
Indexes
-------
Indexes are an essential part of every database, providing
fast access to columns without having to scan each table row
by row.
- MySQL provides only one access method (B-tree) for indexes:
http://www.mysql.com/doc/en/MySQL_indexes.html
- PostgreSQL provides four access methods (B-tree, R-tree, hash and GIST)
which can be used to optimize retrieval strategies according
to need:
http://www.postgresql.org/docs/current/static/sql-createindex.html
Foreign Keys
------------
Explicitly defining relationships between tables is an vital element in
maintaining data integrity. Foreign keys help achieve this by establishing
constraints between keys in different tables, making it impossible e.g.
for a table containing
- In MySQL foreign key support is optionally available as part of the
InnoDB extension:
http://www.mysql.com/doc/en/InnoDB_foreign_key_constraints.html
Under certain circumstances MySQL may ignore foreign key restraints even
though they are correctly defined:
http://www.mysql.com/doc/en/InnoDB_foreign_key_constraints.html
MySQL also parses but silently ignores foreign key syntax in
some situations, even on InnoDB tables:
http://www.mysql.com/doc/en/ANSI_diff_Foreign_Keys.html
- PostgreSQL provides inbuilt and robust foreign key support as
part of its core functionality:
http://www.postgresql.org/docs/7.3/static/sql-createtable.html
Full-text indexing
------------------
Databases storing large amounts of textual data, such as
document repositories and website backend require efficient search
methods which provide intelligent handling of natural language syntax.
Although SQL provides several methods of searching for patterns
in text fields (LIKE, regexes), these do not provide sufficient
functionality for more complex searches, e.g. as used by search engines.
- MySQL provides an integrated index type "FULLTEXT". This
enables simple full-text searches, although facilities
for parsing natural languages apart from a simple, multilingual
stopword list are available. Additionaly, only single-byte character sets
can be indexed, and tables with a FULLTEXT index are not transacton-capable:
http://www.mysql.com/doc/en/Fulltext_Search.html
http://www.mysql.com/doc/en/Fulltext_Restrictions.html
- Through PostgreSQL's extensibilty model several third-party
full-text indexing methods are available. The most advanced is Tsearch2,
which provides advanced full-text searches using multilingual
dictionary-based lookups and stemming, and will be integrated
into PostgreSQL's core functionality in a future release:
http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/
Transaction support
-------------------
Transaction processing is a core element of database systems,
enabling units of work to be encapsulated into a single transaction
Intermediate states between units of work are not visible to other
concurrent transactions, and if some failure occurs that prevents the
transaction from completing, then changes can be rolled back without
affecting the rest of the database.
- MySQL provides transaction support as an optional extra via the
InnoDB extension-Not all table types (e.g. tables defined
with a FULLTEXT index) can be declared as InnoDB tables.
Transactions on a mix of InnoDB and other table types can
lead to transactions which cannot be completely rolled back.
See:
http://www.mysql.com/doc/en/InnoDB_transaction_model.html
- PostgreSQL provides integrated transaction support based on the
MultiVersion Concurrency Control (MVCC) model. All database objects
as well as data definition statements are transaction-capable:
http://www.postgresql.org/docs/current/static/mvcc.html
Other considerations
====================
Licencing
---------
- MySQL is available either under the GPL licence or a MySQL commercial
licence, depending on usage. MySQL licencing policy may be subject to change.
See:
http://www.mysql.com/doc/en/MySQL_licenses.html
- PostgreSQL is available under the BSD licence to both commercial and
non-commercial users. No plans exist to change PostgreSQL licencing. See:
http://www.postgresql.org/licence.html
SQL standards compliance
------------------------
A number of standard definitions for SQL (SQL-89, SQL-92, SQL-99) have been
issued by ANSI/ISO. While no database has achieved 100% standards compliancy,
it is generally regarded as a worthy target to aim for.
Reasons to prefer best-possible standards compliancy :
* flexibility:
less reliancy on proprietary features means
less "lock-in" and easier transition to another database
system should this later become necessary.
* portability:
many applications support more than one database system;
greater SQL dialect deviation increases development and
maintenance time.
* skills:
skill sets developed on a less-standard system are not
so easily transferable, which disadvantages both developers
and employers.
* future-proofing:
A culture of non-standard extensions increases divergence
of SQL dialects, exacerbating the problems described in
the previous points.
- MySQL aims to work towards compliancy with the SQL-99 standard, but will
continue to implement non-standard extensions where it sees fit:
"We are not afraid to add extensions to SQL or support for non-SQL
features if this greatly increases the usability of MySQL Server for
a big part of our users."
( http://www.mysql.com/doc/en/Compatibility.html )
See also:
http://www.mysql.com/doc/en/TODO_future.html
- PostgreSQL aims at full compliance with the most recent SQL standard where
reasonably possible:
"PostgreSQL development tends to aim for conformance with the latest
official version of the standard where such conformance does not contradict
traditional features or common sense."
( http://www.postgresql.org/docs/current/static/features.html )
Supported and unsupported features are listed here:
http://www.postgresql.org/docs/current/static/features.html
http://www.postgresql.org/docs/current/static/unsupported-features-sql99.html
Implementation Details
======================
Many elememnts of SQL supported by MySQL are
not implemented as fully as in PostgreSQL or are
implemented with certain restrictions or
idiosyncracies which may cause unexpected behaviour during
development and production, particularly when porting
SQL to and from other RDBMS. The following lists
some features implemented by PostgreSQL but not MySQL.
SELECT: join clauses
--------------------
FULL OUTER JOIN
- MySQL does not support the FULL OUTER JOIN clause
It is listed in a file named "Todo sometime":
http://www.mysql.com/doc/en/TODO_sometime.html
- PostgreSQL has supported all forms of OUTER JOIN since at least
version 7.1:
http://www.postgresql.org/docs/7.1/static/sql-select.html
UNION
- MySQL supports the UNION clause beginning with version 4.0:
http://www.mysql.com/doc/en/UNION.html
Note that the MySQL UNION implementation contains an interesting
"gotcha": if the first SELECT contains literal values,
subsequent SELECT results will be truncated to the length of those
values:
http://www.mysql.com/doc/en/UNION.html
- PostgreSQL has supported UNION since at least version 6.5:
http://www.postgresql.org/docs/6.5/static/sql-select.htm
INTERSECT
- MySQL does not support the INTERSECT clause. A "Todo sometime":
http://www.mysql.com/doc/en/TODO_sometime.html
- PostgreSQL has supported INTERSECT since at least version 6.5
http://www.postgresql.org/docs/6.5/static/sql-select.htm
EXCEPT
- MySQL does not support the EXCEPT clause. No mention of plans to
introduce support were found in the documentation.
- PostgreSQL has supported EXCEPT since at least version 6.5
(http://www.postgresql.org/docs/6.5/static/sql-select.htm )
Self-referencing table operations:
----------------------------------
INSERT INTO ... SELECT
INSERT INTO ... SELECT ... does not work in MySQL if source and target
tables are the same:
http://www.mysql.com/doc/en/INSERT_SELECT.html
ON UPDATE CASCADE / SET NULL
MySQL's implentation of ON UPDATE does not allow recursive updates on the
same table:
http://www.mysql.com/doc/en/InnoDB_foreign_key_constraints.html
[2. text/plain; pgsql_mysql-short.txt]
This document lists features present in PostgreSQL but not MySQL,
or features present in both databases which the PostgreSQL implementation
provides greater functionality.
It is a condensed version of the document pgsql_mysql.txt, which contains
further annotations and links to each database's documentation
where relevant.
PostgreSQL features not present in MySQL
========================================
Cursors
-------
Cursors enable clients to control the number of result rows
returned from the database by stepping through the result set
in user-defined intervals. This is particularly useful
when manipulating large result sets.
- MySQL has no support for cursors. Implementation
is planned at an unspecified future date.
- PostgreSQL offer advanced cursor support as part of its core
functionality.
External functions
------------------
Specialized applications may require features not part of a
database's core functionality but which rely on direct interaction
with the database engine and cannot be implemented using stored
procedures. This requires the ability to directly extend a database
system with external functions.
- MySQL has only rudimentary and undocumented support for external
functions written in the C language.
- PostgreSQL supports creation of external functions in C and C++
as well as user-defined datatypes for use with external functions.
Many mature third-party extensions to PostgreSQL's core functionality
have been created using this feature.
Sequences
---------
Databases often require the generation of values in sequential
order, e.g. to provide unique values for a table's primary key.
- MySQL provided only a very basic sequence generator called
"AUTO_INCREMENT" which can only be used on primary key columns
to generate values in increments of 1 and when used with transactions
can cause deadlocks.
- PostgreSQL provides flexible sequence support which can generate
values in user-defined increments (both ascending and descending)
between specified minimum and maximum values. PostgreSQL sequences
do not cause deadlocking in transactions.
Stored Procedures
-----------------
Stored procedures are blocks of code stored and executed in
the database backend. They are typically created in an SQL-like procedural
language or a fourth-generation language such as Java or Perl.
- MySQL has no support for any form of stored procedure. Implementation
is planned at an unspecified future date.
- PostgreSQL provides stored procedures in SQL, its own procedural
language PL/PgSQL and a variety of other languages including Perl,
Tcl and Python.
System Catalog
--------------
A system catalog (also known as a "data dictionary") stores
meta-information about a database as normal tables and views.
This enables a DBA to gain information about database operations
and possibly manipulate global database settings.
- MySQL does not have a system catalog, although it does provide
a seperate "mysql" database for manipulating database user permissions.
- PostgreSQL has a system catalog as part of its core functionality.
Beginning with version 7.4 it will also provide database meta-information
via the standardized "information_schema" defined in SQL-92.
Triggers
--------
Triggers are units of code stored in the database which are
executed when certain actions are carried out. They automate
many routine tasks and can be used to enfore data integrity
and business rules.
- MySQL does not support triggers. Implementation
is planned at an unspecified future date.
- PostgreSQL supports triggers (and a related facility called 'rules')
as part of its core functionality. PostgreSQL triggers
can be written in any supported procedural language.
Views
-----
Views are predefined SELECT statements and can be used to simplifiy
complex SELECT statements, restrict user access to underlying tables
or present a consistent view of the database to applications.
- MySQL does not support views. Implementation is planned at an
unspecified future date.
- PostgreSQL supports views as part of its core functionality.
Features present in PostgreSQL and MySQL
========================================
Indexes
-------
Indexes are an essential part of every database, providing
fast access to columns without having to scan each table row
by row.
- MySQL provides only one access method (B-tree) for indexes.
- PostgreSQL provides four access methods (B-tree, R-tree, hash and GIST)
which can be used to optimize retrieval strategies according
to need.
Foreign Keys
------------
Explicitly defining relationships between tables as foreign
keys is an vital element in maintaining data integrity.
- In MySQL foreign key support is optionally available as part of the
InnoDB extension. Under certain circumstances MySQL may ignore
foreign key restraints or correct but unparsed foreign key syntax.
- PostgreSQL provides inbuilt and robust foreign key support as
part of its core functionality.
Full-text indexing
------------------
Databases storing large amounts of textual data require efficient search
methods beyond those provided by the LIKE clause in SELECT statements and
which provide intelligent handling of natural language syntax.
- MySQL provides an integrated index type "FULLTEXT". This
enables simple full-text searches using a stopword list
in single-byte character sets. Tables with a FULLTEXT index are
not transacton-capable.
- Through PostgreSQL's extensibilty model several third-party
full-text indexing methods are available.
The most advanced is Tsearch2, which provides advanced full-text
searches using multilingual dictionary-based lookups and stemming,
and will be integrated into PostgreSQL's core functionality in
a future release.
Transaction support
-------------------
Transaction processing is a core element of database systems,
enabling units of work to be encapsulated into a single transaction
Intermediate states between units of work are not visible to other
concurrent transactions, and if some failure occurs that prevents the
transaction from completing, then changes can be rolled back without
affecting the rest of the database.
- MySQL provides transaction support as an optional extra via the
InnoDB extension. Not all table types (e.g. tables defined
with a FULLTEXT index) can be declared as InnoDB tables.
- PostgreSQL provides integrated transaction support based on the
MultiVersion Concurrency Control (MVCC) model. All database objects
as well as data definition statements are transaction-capable.
Other considerations
====================
Licencing
---------
- MySQL is available either under the GPL licence or a MySQL commercial
licence, depending on usage. MySQL licencing policy may be subject to change.
- PostgreSQL is available under the BSD licence to both commercial and
non-commercial users. No plans exist to change PostgreSQL licencing.
SQL standards compliance
------------------------
A number of standard definitions for SQL (SQL-89, SQL-92, SQL-99) have been
issued by ANSI/ISO. While no database has achieved 100% standards compliancy,
it is generally regarded as a worthy target to aim for.
- MySQL aims to work towards compliancy with the SQL-99 standard, but will
continue to implement non-standard extensions where it sees fit.
- PostgreSQL aims at full compliance with the most recent SQL standard where
reasonably possible.
===
To: pgsql-advocacy-postgresql.org@localhost.postgresql.org
From: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Subject: Re: [pgsql-advocacy] PostgreSQL <> MySQL: first draft
Date: Mon, 15 Sep 2003 10:11:15 +0800
Mention partial and expressional indexes under the Indexes section - they're
biggies that MySQL doesn't have.
===
To: pgsql-advocacy-postgresql.org@localhost.postgresql.org
From: Alexey Borzov <borz_off@cs.msu.su>
Subject: [pgsql-advocacy] PostgreSQL <> MySQL: missing the point?
Date: Mon, 15 Sep 2003 13:29:44 +0400
Hi!
I sometimes have fun flaming about MySQL vs. PostgreSQL on
various Russian-language forums. This is an enlightening
experience, 'cause you see what sort of advocacy is really
needed and really helps building up your flaming skills, as
there are many Russian-speaking developers in MySQL AB now.
Thus much praise goes to Ian for compiling his excellent
"gotchas" list that can help a lot in flaming. But I see no
such use for "the bullet list": I don't see target audience
for it.
There are 2 sorts of people using MySQL:
1) Those who know several RDBMSs and use it only when it is
the best tool for the job (read-only web DB, storing
logs, etc)
2) Those who know only MySQL and think that it is the
Ultimate Solution for Everything.
The propaganda should obviously be directed to the category
2) and if you look at MySQL's propaganda, it is. The "bullet
list" will not help here, as these people do not know SQL
and RDBMS theory past MySQL manual and do not want to learn,
while they *think* that MySQL satisfies their needs and will
satisfy them for some time.
Thus what is really needed is *not* technical document, but
a healthy dose of FUD / debunking directed at
MySQL. Consider "Why not MySQL?" document by OpenACS
developers, but newer and better.
Some suggestions for such a document:
Development strategies:
* PgSQL has an open development model and open architecture,
while MySQL is developed by MySQL AB only and is
closed. Thus there are third-party solutions for
PostgreSQL (PostGIS, tsearch, various replication
packages), but not for MySQL.
* "Premature optimization is a root of much evil" --- an
excellent counter-FUD for MySQL's "speed is a priority"
* I remember finding an email by Monty on mysql list
archive, dated 1998(?) where he promised MySQL 4.0 Really
Soon Now
Licensing:
* MySQL had atleast 2 license changes, PostgreSQL had none.
* Various companies that distribute and support PostgreSQL
vs. MySQL AB/Nusphere dispute
Data integrity:
* Ways to lose your data with MySQL --- Ian's gotchas list
* If MySQL is so stable, why does it have myisamchk utility
and *built-in* REPAIR TABLE command?
* InnoDB's hot backup utility is not free: either
transactions or "hot" backup.
Functionality
* OK, bullet list here.
Speed:
* PostgreSQL's functional and partial indexes: KILLER
feature that should be SHOUTED about.
* Benchmarking queries vs. benchmarking applications with a
s*itload of workarounds
MySQL current favourite is eweek's benchmark (
http://www.eweek.com/article2/0,3959,1184846,00.asp ) , it
should be debunked:
* The queries are really simple
* The specification was written in a way to work around MySQL's shortcomings
* MySQL's performance is great only with "cache", but every
other database can have an app-level cache, too.
How does it sound?
===
To: pgsql-advocacy-postgresql.org@localhost.postgresql.org
From: Kaarel <kaarel@future.ee>
Subject: Re: [pgsql-advocacy] PostgreSQL <> MySQL: missing the point?
Date: Mon, 15 Sep 2003 13:17:10 +0300
> * If MySQL is so stable, why does it have myisamchk
> utility and *built-in* REPAIR TABLE command?
Perhaps this is one of the reasons and it's probably
somewhere in the documentation too so it cannot be a bug
therefore it must be a feature :)
Heikki Tuuri "'nosync' is dangerous. If there is a power
outage, or the OS crashes, there is a great chance that your
tablespace will be corrupted. MyISAM always runs in the
'nosync' mode, that is, it never calls fsync() to flush the
files to disk."
http://lists.mysql.com/mysql/148920
===
To: pgsql-advocacy-postgresql.org@localhost.postgresql.org
From: Alexey Borzov <borz_off@cs.msu.su>
Subject: Re: [pgsql-advocacy] PostgreSQL <> MySQL: missing the point?
Date: Mon, 15 Sep 2003 18:42:47 +0400
Hi!
Michael Pohl wrote:
>>There are 2 sorts of people using MySQL:
>> 1) Those who know several RDBMSs and use it only when it
>> is the best tool for the job (read-only web DB, storing
>> logs, etc)
>> 2) Those who know only MySQL and think that it is the
>> Ultimate Solution for Everything.
> 3) Programmers (read: not db experts) who started with
> MySQL by default or
> by recommendation, but who would be persuaded by an objective, non-FUD
> comparison to a more capable free RDBMS.
> This is the category I fell into three years ago. Ian's
> bullet list would
> have saved me a lot of research back then.
You've got a point here.
But I must admit that I've seen few people falling into this
category, much less than 2). Besides, I think this bullet
list is a Good Idea, just not stand-alone but inside a
propaganda framework.
> As a side note, I appreciate the PgSQL community's apparent commitment to
> avoid both FUD and overstatement of PgSQL's capabilities.
If you look closely at my list, it has no overstatements. It
has no false statements either, everything can be backed up
by appropriate links.
As for the FUD, its main goal is to point some obvious things:
1) MySQL is not exactly Free Software
2) While missing features do get implemented, they may take
some time to wait for:
http://www.geocrawler.com/mail/msg.php3?msg_id=1061364&list=194
3) Data integrity is good. You can get fired if you f*ck up your data.
4) Speed is important, but in *your* application, not in
some suspicious benchmarks (and understand why they are
suspicious).
5) You can save your valuable time if you use advanced
features instead of work around lack of them.
Consider this FUD a "wake up" call for those whose only
database-related reading is MySQL manual.
===
To: pgsql-advocacy-postgresql.org@localhost.postgresql.org
From: Sean Chittenden <sean@chittenden.org>
Subject: Re: [pgsql-advocacy] PostgreSQL <> MySQL: first draft
Date: Mon, 15 Sep 2003 11:25:04 -0700
> Stored Procedures
> -----------------
>
> Stored procedures are blocks of code stored and executed in
> the database backend. They are typically created in an SQL-like procedural
> language or a fourth-generation language such as Java or Perl.
>
> - MySQL has no support for any form of stored procedure. Implementation
> is planned at an unspecified future date:
> http://www.mysql.com/doc/en/ANSI_diff_Triggers.html
>
> - PostgreSQL provides mature and tested support for function creation
> in SQL and the following procedural languages:
> PL/PgSQL (PostgreSQL's own procedural language, similar
> to e.g. Oracle's PL/SQL)
> Perl
> Python
> Tcl
pl/ruby exists too:
http://moulon.inra.fr/ruby/plruby.html
===
To: pgsql-advocacy-postgresql.org@localhost.postgresql.org
From: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Subject: Re: [pgsql-advocacy] PostgreSQL <> MySQL: first draft
Date: Tue, 16 Sep 2003 09:05:04 +0800
> > - PostgreSQL provides mature and tested support for function creation
> > in SQL and the following procedural languages:
> > PL/PgSQL (PostgreSQL's own procedural language, similar
> > to e.g. Oracle's PL/SQL)
> > Perl
> > Python
> > Tcl
>
> pl/ruby exists too:
>
> http://moulon.inra.fr/ruby/plruby.html
And pljava (aka plpga):
pljava.sourceforge.net
===
To: pgsql-advocacy-postgresql.org@localhost.postgresql.org
From: Hornyak Laszlo <kocka@tigrasoft.hu>
Subject: Re: [pgsql-advocacy] PostgreSQL <> MySQL: first draft
Date: Tue, 16 Sep 2003 03:34:13 +0200 (CEST)
On Tue, 16 Sep 2003, Christopher Kings-Lynne wrote:
> > > - PostgreSQL provides mature and tested support for function creation
> > > in SQL and the following procedural languages:
> > > PL/PgSQL (PostgreSQL's own procedural language, similar
> > > to e.g. Oracle's PL/SQL)
> > > Perl
> > > Python
> > > Tcl
> >
> > pl/ruby exists too:
> >
> > http://moulon.inra.fr/ruby/plruby.html
>
> And pljava (aka plpga):
:)) Yes but there is no working version of it on the network. But don`t
believe the sf.net statistics, we are working on it offline. Net
connection is too expensive :(
(The word java is trademarked both by people of Java island or Sun
microsystems inc. so we can not call it 'java'. Hopefully the 'j' wont be
a trademark of anyone.)
===
To: pgsql-advocacy-postgresql.org@localhost.postgresql.org
From: "Joshua D. Drake" <jd@commandprompt.com>
Subject: Re: [pgsql-advocacy] PostgreSQL <> MySQL: first draft
Date: Mon, 15 Sep 2003 18:53:43 -0700
Don't forget plPHP ;)
===
To: pgsql-advocacy-postgresql.org@localhost.postgresql.org
From: Robert Treat <xzilla@users.sourceforge.net>
Subject: Re: [pgsql-advocacy] PostgreSQL <> MySQL: first draft
Date: 16 Sep 2003 08:31:49 -0400
On Mon, 2003-09-15 at 21:05, Christopher Kings-Lynne wrote:
> > > - PostgreSQL provides mature and tested support for function creation
> > > in SQL and the following procedural languages:
> > > PL/PgSQL (PostgreSQL's own procedural language, similar
> > > to e.g. Oracle's PL/SQL)
> > > Perl
> > > Python
> > > Tcl
> >
> > pl/ruby exists too:
> >
> > http://moulon.inra.fr/ruby/plruby.html
>
> And pljava (aka plpga):
>
> pljava.sourceforge.net
>
plr (http://www.joeconway.com/plr/)
plsh (http://developer.postgresql.org/~petere/plsh.html)
plmono (http://gborg.postgresql.org/project/plmono/projdisplay.php)
===