Stuff like this is one of the reasons I think Postgres isn't taking off. Pg zealots seem to be fixated on ancient problems with mysql and wont acknowledge that they've been addressed. The result is people think "raving lunatic" when they think about Postgres.

The cheap shot about mysql and foreign keys only being supported started with mysql 5 needs to be removed from the guide. Its completely bogus. The bogus sentence is (engrish alert):

Quote:

Most of the standard features such as FOREIGN KEY was only just added in MySQL 5.

Stuff like this is one of the reasons I think Postgres isn't taking off. Pg zealots seem to be fixated on ancient problems with mysql and wont acknowledge that they've been addressed. The result is people think "raving lunatic" when they think about Postgres.

The cheap shot about mysql and foreign keys only being supported started with mysql 5 needs to be removed from the guide. Its completely bogus. The bogus sentence is (engrish alert):

Quote:

Most of the standard features such as FOREIGN KEY was only just added in MySQL 5.

While I would remove any comparison of MySQL and PostgreSQL in a user guide to either of them neither your statement nor the one in the aforementioned doc is properly accurate. By default, last I knew, InnoDB was not default (i.e. standard) storage engine, and as that is the only place foreign keys were supported (every else it just silently ignores which IMO is the worst failing of MySQL - it's tendency to not tell you things like that). As such IF I were force to include the reference I would make it clear that while MyISAM will accept the FOREIGN KEY declaration it will silently ignore it and that you need to use InnoDB if you need actual support. I know of many people that got bit by taking statements like yours as MySQL supporting transaction and doing their code that way without realizing that others may not have their DB set to use InnoDB and then encounter user problems because the install of the application was on an MySQL server that was not using InnoDB. IMO to say that pre-5 MySQL support foreign keys is like saying PostgreSQL supports replication. Neither of them were/are standard, nor meet the expectations of saying they are (like foreign keys on temp tables not working in MySQL, and significant deviation for the SQL standard re: foreign keys on MySQL).

But like I said, comparisons do not belong in virtually any user guide.

Things like is one of the reasons PostgreSQL *is* becoming increasingly popular as people get bit by MySQL "choices" (especially at the large corps and financial firms I deal with). This is just one item among many. PG has it's issues (can you say DB upgrades?) but I'd prefer to have them then data getting silently changed under my feet because the DB assumes your first time stamp field on a table is something it should update to the current time every time it modifies that entry.

As far as zealotry, I see far, far more of that from MySQL users. I've never gotten a glare from a PostgreSQL proponent by suggesting MySQL. A raised eyebrow or two, sure. But never a glare or a glare followed by a lecture about how MySQL is "soo much faster" (again not true they are pretty close to the same), or outright hostility. I can't say the reverse however.

So how do we get the opening bits of this doc fixed (or anything else that needs updated). If it's been a year between these comments, whatever method was tried before has not worked.

While I would remove any comparison of MySQL and PostgreSQL in a user guide to either of them neither your statement nor the one in the aforementioned doc is properly accurate. By default, last I knew, InnoDB was not default (i.e. standard) storage engine...

It seems another Postgres Zealot looks past the truth ... Lets review the original again shall we?

PostgreSQL Guide Feedback wrote:

Most of the standard features such as FOREIGN KEY was only just added in MySQL 5.

There is no claim to what the "default storage engine" is, only to the support of the feature.

Maybe you could say a word to i18n and creating a database with a certain encoding or locale and its effects and consequences. I currently do not understand this myself, but in case somebody answers my question, you may might want to add this information

Helpful, indeed.
However, I would drop the PostgreSQL SQL intro - the PostgreSQL manual online - http://www.postgresql.org/docs/8.0/interactive/ddl.html - covers the topic a bit more in details.
It would however be more interesting to call attention to the scripting possibilities of Pg, the inheritance, special datatypes and some notes on tweaking and probably schemas.
Also the external projects are interesting - as I recall there is a GPS related extension around.