Slashdot Mirror

Oracle has a serious hard-on for Java, which you can see because it is the only major database I know of that allows you to use Java in place of PL/SQL.

Most databases have similar features, for example Sybase ASE & PostgreSQL.

Currently they are claiming production environments in excess of 4Tb, and maximum rows is now unlimited.
http://www.postgresql.org/about/

When people stop using databases, what does Oracle really have?

People won't stop using databases, but when people stop using its flagship database software, Oracle will have what PostgreSQL fans like to call an elephant in the room.

No, you're an idiot. If it's not the GPL,then it's merely a "compatible" license and it isn't really Open Source. Anything that doesn't enforce freedom for the modified code is not really Open Source. It's being a fence-sitting coward. Real Open Source developers aren't afraid to make a statement and stand up for what's right.

You're confusing "Free Software", as in the Free Software Foundation that started the GPL, with Open Source. Free Software licences use copyright to enforce source distribution requirements for redistributed modified code. Open Source just indicates that the source is available. For the BSD/MIT/PostgreSQL licences they also state that the authors are not liable, and original development credit has to be given in any derivative work. The key words are right there in the names: Free, as in the defence of freedoms and associated rights, vs. Open Source, where the source is made available with the code (i.e. open for viewing).

"PostgreSQL is released under the PostgreSQL License, a liberal Open Source license, similar to the BSD or MIT licenses"

The BSD and MIT open source licences precede the GPL by quite a time margin. The PostgreSQL licence doesn't coerce developers to release the source for any updates that they make, just to give appropriate credit to the PostgreSQL developers. However, many of the same software freedoms exist with BSD/MIT/PostgreSQL as with GPL. At any time, should anybody take core PostgreSQL development into a direction which is unacceptable to the rest of the community, or should the main organizations involved in PostgreSQL development terminate their support for continued open development (either due to business goals or lack of funds), any group can take over the existing code base, fork it and continue development in an open manner. The PostgreSQL licence doesn't coerce the release of modifications or patents back into the commons the way the GPL does, but it provides many of the other freedoms available from the GPL. This process has been successfully demonstrated, most notably with the double forking over a span of decades from X Consortium->xFree86->x.Org, through the use of the X11/MIT licence

Oh well, IHPBT since you now appear to be trying to start a flame war.

Don't know about mysql, but postgres has an "inet" row type which is intended for storing network addresses, it supports ipv6 as well as v4 and even has a bunch of functions built in for calculating netmasks... I have a php app which deals with port scan results and talks to a postgres backend and it makes heavy use of these functions.

It does seem as if the functions are a little more limited when it comes to v6, but you can store addresses just fine:

http://www.postgresql.org/docs/8.2/static/functions-net.html

If you have something more complex than a flat file, then use relational databases. Even Access databases are better than a collection of text files.

That really depends on what your intended use for them is. I mean I don't know this particular fellow's situation for data collection or what tools he uses for reporting and visualization but perhaps, for him, it's a much better idea to store them in flat files. Me? I have been using flat files for all my data collection about local crime (see here, here, here, and here) for several reasons:

1. I script it all with awk/sed to scrape the data and then put it in a CSV for summary with PostgreSQL.

2. Yes, I could use PostgreSQL for it all but I like to easily see it in its raw format on another remote machine. I also like to use Excel to do ad-hoc pivots and this is the easiest way for me to do that.

3. I upload the data to Google Docs and use their gadgets to make charts for my dashboards and maps. If I were to store it solely in PostgreSQL I would have to make the CSV, pipe it into the PostgreSQL, convert it back out to CSV and then upload it. An additional step for nothing.

Hey, no method is perfect for everyone and every project is a little different and while it's hard for me, based on the information provided, to give this guy any help, automatically suggesting that he needs a relational database to do his data storage might be just a little shortsighted.

YMMV.

There, fixed that for 'ya.

If you have something more complex than a flat file, then use relational databases. Even Access databases are better than a collection of text files.

That really depends on what your intended use for them is. I mean I don't know this particular fellow's situation for data collection or what tools he uses for reporting and visualization but perhaps, for him, it's a much better idea to store them in flat files. Me? I have been using flat files for all my data collection about local crime (see here, here, here, and here) for several reasons:

1. I script it all with awk/sed to scrape the data and then put it in a CSV for summary with PostgreSQL.

2. Yes, I could use PostgreSQL for it all but I like to easily see it in its raw format on another remote machine. I also like to use Excel to do ad-hoc pivots and this is the easiest way for me to do that.

3. I upload the data to Google Docs and use their gadgets to make charts for my dashboards and maps. If I were to store it solely in PostgreSQL I would have to make the CSV, pipe it into the PostgreSQL, convert it back out to CSV and then upload it. An additional step for nothing.

Hey, no method is perfect for everyone and every project is a little different and while it's hard for me, based on the information provided, to give this guy any help, automatically suggesting that he needs a relational database to do his data storage might be just a little shortsighted.

YMMV.

There, fixed that for 'ya.

If you have something more complex than a flat file, then use relational databases. Even Access databases are better than a collection of text files.

That really depends on what your intended use for them is. I mean I don't know this particular fellow's situation for data collection or what tools he uses for reporting and visualization but perhaps, for him, it's a much better idea to store them in flat files. Me? I have been using flat files for all my data collection about local crime (see here, here, here, and here) for several reasons:

1. I script it all with awk/sed to scrape the data and then put it in a CSV for summary with PostgreSQL.

2. Yes, I could use PostgreSQL for it all but I like to easily see it in its raw format on another remote machine. I also like to use Excel to do ad-hoc pivots and this is the easiest way for me to do that.

3. I upload the data to Google Docs and use their gadgets to make charts for my dashboards and maps. If I were to store it solely in PostgreSQL I would have to make the CSV, pipe it into the PostgreSQL, convert it back out to CSV and then upload it. An additional step for nothing.

Hey, no method is perfect for everyone and every project is a little different and while it's hard for me, based on the information provided, to give this guy any help, automatically suggesting that he needs a relational database to do his data storage might be just a little shortsighted.

YMMV.

There, fixed that for 'ya.

If you have something more complex than a flat file, then use relational databases. Even Access databases are better than a collection of text files.

That really depends on what your intended use for them is. I mean I don't know this particular fellow's situation for data collection or what tools he uses for reporting and visualization but perhaps, for him, it's a much better idea to store them in flat files. Me? I have been using flat files for all my data collection about local crime (see here, here, here, and here) for several reasons:

1. I script it all with awk/sed to scrape the data and then put it in a CSV for summary with PostgreSQL.

2. Yes, I could use PostgreSQL for it all but I like to easily see it in its raw format on another remote machine. I also like to use Excel to do ad-hoc pivots and this is the easiest way for me to do that.

3. I upload the data to Google Docs and use their gadgets to make charts for my dashboards and maps. If I were to store it solely in PostgreSQL I would have to make the CSV, pipe it into the PostgreSQL, convert it back out to CSV and then upload it. An additional step for nothing.

Hey, no method is perfect for everyone and every project is a little different and while it's hard for me, based on the information provided, to give this guy any help, automatically suggesting that he needs a relational database to do his data storage might be just a little shortsighted.

YMMV.

There, fixed that for 'ya.

...I would immediately make a large donation to PostgreSQL - the arch enemy for all Oracle database solutions. Just to spite them.

You are correct. PostgreSQL does have this problem, and it apparently cannot be disabled. See here.

As I mentioned elsewhere, MySQL can enable this dangerous behavior, but does not do it by default. You are correct that PostgreSQL is fully vulnerable to this problem. No option to turn it off either, apparently.

As I indicated earlier, MySQL has an option for this, but does not do it by default.

I stand corrected on PostgreSQL. Apparently, the developers showed the same lack of foresight as the Sybase / MS SQL developers did. Or perhaps bad ideas are contagious.

In any case, all the databases that support this behavior ought to deprecate and disable it, because in the real world, it is an invitation for severe problems. Sort of like opening root shell access to a random passersby by accident.

And discussion also spells out why this wouldn't likely happen in a LAMP scenario -- no multiple query commands by default.

This statement is not entirely true. If you see MySQL and PostgreSQL documentation you'll see that both support the same sort of technique. Different frameworks may try mitigate (some versions of PHP may take a dim view to multiple statements in a single query for MySQL as an example, but the PHP docs for Postgre say that PgSQL will in fact run every statement you include in your query).

Really? I didn't realise that MySQL and PostgreSQL weren't databases!

Not even close. MSSQL and Sybase are the only databases that are vulnerable to this form of SQL injection (in combination with sloppy programming).

Really? I didn't realise that MySQL and PostgreSQL weren't databases!

Sorry. There are no databases other than MS SQL, Sybase, and derivatives that allow the injection of an entirely new SQL statement where a literal belongs. It is due to the way they support combining multiple statements separated by semicolons.

Wrong.

http://dev.mysql.com/doc/refman/5.0/en/c-api-multiple-queries.html

Also:

http://www.postgresql.org/docs/6.4/static/install12418.htm

"(Get in the habit of including those SQL semicolons. Psql won't execute anything until it sees the semicolon or a "\g" and the semicolon is required to delimit multiple statements.)"

I made a lot of mistakes that I would not have made with MySQL, mostly with privileges.

Can you elaborate? The complaint that I saw most often was that there was no good way to manage the permissions for a lot of objects. In 9.0, that was addressed with GRANT/REVOKE IN SCHEMA.

Also, keep in mind that the standard has a lot to say about the privilege system, so postgresql won't want to stray too far from that.

but if MySQL works for you...cheaper...and easier, why not use it?

Of course, go for it.

Just don't let inertia keep you from learning something that might really be an improvement. "Works" is not binary -- some things work better than others. SVN works. Git works better. Notepad and GEdit work. Emacs and vim work better.

Do you have an actual example?

Here's some cut-n-paste action and some additional reading.

Join removal -- this is a feature that will remove joins from the execution plans where they are not needed. For example where you have a left join that doesn't appear in a where or as a column in select. This is important for people like us that rely on views to allow less skilled users to be able to write meaningful queries without knowing too much about joins or creating ad-hoc query tools that allow users to pick from multiple tables

And it continues with:

When people talk to me about the (limited implementation of) join removal that will be part of PostgreSQL 9.0, the conversation usually goes in two ways. Some people ask how the feature works and then say something like "oh, I guess that could be useful every once in a while". Other people already know exactly how the feature works and usually say some variant of "this is an amazingly wonderful feature that I am looking forward to with great enthusiasm".

The difference between these two groups of people (I think) is not so much their level of technical knowledge or how closely they've been following pgsql-hackers, but their use case. If your database is primarily a data warehouse, my guess is that you won't have many occasions to benefit from join removal. Where this feature really comes in handy is in OLTP workloads with highly normalized data, in situations where users are generating queries against views (perhaps through some sort of reporting interface) and expecting to get results back immediately.

Let's take an example...

You can read more about Why Join Removal is Cool as well as lots more general information on the new PostgreSQL features at Planet PostgreSQL.

Can you explain the new built in replication's conflict handling to me?

According to the docs, it looks like the major conflicts are basically exclusive lock issues. Since it's a one-way replication system, the standby server can't block the primary server from allowing the user to lock a table, so it has to break queries in order to comply. The table locks are used for ALTER and DROP TABLE commands. The other issue is that the VACUUM process removes rows from the database that are no longer visible to any transactions it knows about, and this too is written in to the WAL and communicated to the standby server, so VACUUMing the primary can delete rows that old transactions on the standby server are still looking at.

Last I checked the indexes don't contain transaction data (from 2007: "why is count(*) so slow?") so if you just looked at the index, you might still get the wrong answer. Maybe adding transaction windows to indexes is what this is waiting on? (can't see that not suck either performance-wise or storage-wise though).

Some things they just don't *want* to implement on ideological reasons, like "UPDATE OR INSERT" or "CREATE IF NOT EXISTS" in PostgreSQL at least.

Definitely not true. There's a lot of support to implement the MERGE command from the SQL standard. It's been proposed a few times, but it's more difficult than it sounds to implement. From here:

And work on MERGE support is itself blocked behind the fact that PostgreSQL doesn't have a good way to lock access to a key value that doesn't exist yet--what other databases call key range locking. See the notes for "Add SQL-standard MERGE/REPLACE/UPSERT command" at http://wiki.postgresql.org/wiki/Todo for more information.

Your gripe about CREATE ... IF NOT EXISTS might hold water, depending on what exactly you're complaining about (CREATE TABLE? Or for indexes/constraints?). There does seem to be some resistance to CINE, though from what I can tell it's mostly because people would rather have CREATE OR REPLACE, but COR is much harder to implement (what do you do when the object already exists, but is slightly different than the one you're trying to create)?

Some things they just don't *want* to implement on ideological reasons, like "UPDATE OR INSERT" or "CREATE IF NOT EXISTS" in PostgreSQL at least.

Definitely not true. There's a lot of support to implement the MERGE command from the SQL standard. It's been proposed a few times, but it's more difficult than it sounds to implement. From here:

And work on MERGE support is itself blocked behind the fact that PostgreSQL doesn't have a good way to lock access to a key value that doesn't exist yet--what other databases call key range locking. See the notes for "Add SQL-standard MERGE/REPLACE/UPSERT command" at http://wiki.postgresql.org/wiki/Todo for more information.

Your gripe about CREATE ... IF NOT EXISTS might hold water, depending on what exactly you're complaining about (CREATE TABLE? Or for indexes/constraints?). There does seem to be some resistance to CINE, though from what I can tell it's mostly because people would rather have CREATE OR REPLACE, but COR is much harder to implement (what do you do when the object already exists, but is slightly different than the one you're trying to create)?

Some things they just don't *want* to implement on ideological reasons, like "UPDATE OR INSERT" or "CREATE IF NOT EXISTS" in PostgreSQL at least.

Definitely not true. There's a lot of support to implement the MERGE command from the SQL standard. It's been proposed a few times, but it's more difficult than it sounds to implement. From here:

And work on MERGE support is itself blocked behind the fact that PostgreSQL doesn't have a good way to lock access to a key value that doesn't exist yet--what other databases call key range locking. See the notes for "Add SQL-standard MERGE/REPLACE/UPSERT command" at http://wiki.postgresql.org/wiki/Todo for more information.

Your gripe about CREATE ... IF NOT EXISTS might hold water, depending on what exactly you're complaining about (CREATE TABLE? Or for indexes/constraints?). There does seem to be some resistance to CINE, though from what I can tell it's mostly because people would rather have CREATE OR REPLACE, but COR is much harder to implement (what do you do when the object already exists, but is slightly different than the one you're trying to create)?

I see the replication feature as being more about perception than anything else.

Postgresql has long had a variety of replication options outside of the core that serve various needs, but it seems that the perception out in the community remained that postgresql was a stable, stand-alone database, and getting replication to work on top involved "hacks", while mysql, despite its faults, had "solid" replication that lent itself better to large installations.

Of course this perception is far from reality, but it has been deemed a serious enough problem for the postgres team to finally include replication in the core.

A better summary of the changes is here.

After years of resisting, one of the more significant changes is the inclusion of WAL shipping-based replication into postgresql core, and the ability to do read-only queries on the standby systems. This will hopefully go a long way towards appeasing mysql users used to the "easy" replication that mysql provides.

Companies that support open source projects make money in other venues, often supported at their base by the very non-profit open source that they support.

I can see how one could sell support contracts for certain kinds of software like MySQL and Solaris. But not all categories of free software are as amenable to support contracts. Examples include computer games that aren't massively multiplayer.

Other companies buy up projects to kill them.

Oracle may be planning to do this to MySQL, which was largely developed within the MySQL AB cathedral that Oracle acquired. On the other hand, PostgreSQL's major contributors are too diverse in organizational affiliation for this to be an easy job for Oracle.

Can you give any specifics? Btw, you know that there is more than one isolation level available in Postgres?

Out of curiosity, what about the appengine behavior, in which there is only a single version that succeeds, and any concurrent transactions that affect the same entity group fail?

That is precisely how snapshot isolation using MVCC works. I know that it is available in at least Oracle, MSSQL, Postgres and Firebird, out of relational databases I have any experience with. The complete list is probably longer.

Does any existing database do it this way? And more importantly, can you query on the members of said array? In the above key example, a query for "Which records are tagged with a given tag?" is stupidly simple.

Yes. See docs PostgreSQL arrays for a comprehensive coverage, but the gist of it would be:

CREATE TABLE foo (bar TEXT[])
SELECT * FROM foo WHERE ANY(bar) = "tag"

though such a search would be O(n) for every array (which, of course, isn't a problem for your designated use case of tag clouds).

Interbase and Firebird also have arrays, though last I checked, no built-in facilities for searching them in this manner (though an UDF can be written in C to do that, or a third-party one can be used).

I don't know of other databases, save that MSSQL does not have this out of the box. Since it allows to extend both column types and functions via any .NET language, adding that would be trivial.

Great, what about YAML? What about ID3 tags on MP3s?

You can, obviously, shove anything into a blob or a text field - the DB won't preclude you from doing so. Querying it is also not a problem if the DB in question allows for custom user-defined functions written in a foreign language (practically all modern RDBMS do). Such a query will still be parallelized - it won't parallelize the body of your function, of course, but it will parallelize the application of that function to rows.

A Map function is an arbitrary bit of code in a Turing-complete language which executes over every element in a given set, creating an arbitrary number (zero or more) corresponding elements which form the result set.

That's what SELECT does, for a set of tuples (which can, of course, be single-element).

Now, I'm not aware of a standard ANSI SQL way to get multiple output tuples from a single input one (though I suspect there is something in SQL99 or SQL03 additions). In MSSQL, I can define a UDF (written in T-SQL, with CREATE FUNCTION) that produces a table value from its input parameters, and then join on that. For example:

CREATE FUNCTION map_x_to_ys(@x INTEGER) RETURNS @ys TABLE(y INTEGER) AS
BEGIN
DECLARE @i INTEGER
SET @i = 0
WHILE @i < @x
BEGIN
INSERT INTO @ys VALUES (@i)
SET @i = @i + 1
END
END

SELECT ys.y
FROM xs
CROSS APPLY map_x_to_ys(xs.x) AS ys

assuming that "xs" is a table (or a table-type value coming from another query). APPLY here is MSSQL shorthand for this kind of join, which avoids the needs to output keys in the UDF to later join on in SELECT. Effectively, SELECT..APPLY in MSSQL is precisely the "map" part of MapReduce, with exact same semantics.

In other SQL DBs, the same kind of thing - when you need multiple output values per each input value - could be achieved by using plain joins, albeit with a few more hoops to jump through. I suspect that those with array data types will let you use them to avoid joins, as well.

A Reduce function is an arbitrary bit of code in a Turing-complete language which executes once for every element in a given set, taking that element and the result of reduce on the previous element as input, thus creating a s

MySQL replication barely deserves the name. It plain and simple DOES NOT guarantee data consistency. Maybe it's nice and easy to work with, but I would never trust mission-critical data to it.

I know that replication has been the sore point of PostgreSQL, mainly because there were several different approaches being developed--all provided as external solutions, and it could be confusing to try and wade through all the data to find the best option. Fortunately, version 9.0 (moving from alpha to beta soon) will come with built-in hot standby and streaming replication.

Some other bloke in another part of the discussion said, Third, PostgreSQL has excellent performance, and PostgreSQL does, in fact, scale horizontally

Can't say I know which of you is right.

First of all, if he's asking Slashdot for advice (which is barely a step above reading tea leaves [which itself is a step above asking 4chan]), he doesn't need Facebook-level scalability.

Second, you're confusing scalability and performance. Scalable solutions tend to actually be slower than non-scalable ones: the difference is that a scalable system increases in capacity linearly with the number of machines you throw at it ("horizontal" scalability), whereas a fast non-scalable system generally needs the same number of faster, individual machines to increase capacity ("vertical" scaling).

Third, PostgreSQL has excellent performance, and PostgreSQL does, in fact, scale horizontally.

MySQL needs to be forked, before it gets forked in the rear by Oracle.

Or you could just use PostgreSQL instead.

That's actually something they just added in 8.4. I wrote a little bit about using this functionality on my blog. The syntax is different than Oracle's though.

See this: Continuous Archiving and Point-In-Time Recovery (PITR). PostgreSQL is becoming more sophisticated every day, and redundant hardware is reducing the need for sophistication.

A different opinion: Maybe the combination of Sun and Oracle will be called Snoracle.

I think Oracle is on the way down. In the future, companies will run cheap, redundant hardware with PostgreSQL.

Google is already doing something like that. You can see for yourself: Google uncloaks once-secret server.

A lot of what caused the purchase of expensive Sun servers in the past was ignorance. CEOs could be convinced the spending a lot of money with Sun was the only way to have enterprise operations, and they bought Sun equipment rather than using Linux and PostgreSQL. Now there is less ignorance. Many corporate needs can be served with much less expense.

MySQL? Try a real database.

In the case of MySQL, stop using a toy and start using a REAL database.

http://www.postgresql.org/about/featuredetail/feature.67

What, you aren't already?

Funny thing: MySQL's website says

The world's most popular open source database

PostgreSQL's website says

The world's most advanced open source database

I've always preferred PostgreSQL over MySQL ;-)

you have to have concurrency issues completely nailed down (ideally with row level locking and ACID).

Even row-level locking ends up being a scalability issue eventually. This is why PostgreSQL uses MVCC for transaction isolation by default instead, which is one of the reasons it can scale upward well for some types of workloads.

At which point NTT would promptly hire/promote someone else into the same position with the same level of resources necessary to be effective. For example, in addition to committer Itagaki Takahiro, they also have some major work on replication being led by Masao Fujii. The point of having a big company like NTT involved is that you can't just make their need for PostgreSQL to be successful go away so easily. There's not just "that one NTT employee"--he's one of a whole team there doing PostgreSQL related work.

I would like to have a list of serious companies using PostgreSQL for serious stuff

PostgreSQL Featured Users; Quotes has additional detail about the scope of some of those. Most people are probably familiar with names like Skype and Cisco on there, but less well known companies like NTT are huge too--and they even sponsor a good chunk of PostgreSQL development because it's so heavily used there.

And those are just the public record. Because of its BSD license, PostgreSQL also gets used in plenty of places that don't talk about what they're doing with it. For example, I've worked with financial companies that are cutting loose Oracle for PostgreSQL whenever feasible, and with some US defense companies that use PostGIS for geographic databases. (looks out window) I may have already said too much.

I would like to have a list of serious companies using PostgreSQL for serious stuff

PostgreSQL Featured Users; Quotes has additional detail about the scope of some of those. Most people are probably familiar with names like Skype and Cisco on there, but less well known companies like NTT are huge too--and they even sponsor a good chunk of PostgreSQL development because it's so heavily used there.

And those are just the public record. Because of its BSD license, PostgreSQL also gets used in plenty of places that don't talk about what they're doing with it. For example, I've worked with financial companies that are cutting loose Oracle for PostgreSQL whenever feasible, and with some US defense companies that use PostGIS for geographic databases. (looks out window) I may have already said too much.

I would like to have a list of serious companies using PostgreSQL for serious stuff

PostgreSQL Featured Users; Quotes has additional detail about the scope of some of those. Most people are probably familiar with names like Skype and Cisco on there, but less well known companies like NTT are huge too--and they even sponsor a good chunk of PostgreSQL development because it's so heavily used there.

And those are just the public record. Because of its BSD license, PostgreSQL also gets used in plenty of places that don't talk about what they're doing with it. For example, I've worked with financial companies that are cutting loose Oracle for PostgreSQL whenever feasible, and with some US defense companies that use PostGIS for geographic databases. (looks out window) I may have already said too much.

PostgreSQL starting storing NUMERIC columns in base 10000 six or seven years ago. A nice trick, but not exactly rocket science. If you have a high school level education in computer science, you should know how to do stuff like this. Maybe that is what the patent examiners need.

But I assume the database vendors know what they are doing, and they seem to assume true floating point decimal is needed, not just fixed point.

Funny but the money data type has been in Microsoft SQL Server since SQLSrvr2000, and there's at least one other. But yeah, Oracle currently only supports BCD-style Numeric(). Of course there's a lot of non-financial data that's better suited to floating point.

But the important point is that, unless you've got infinite memory to hold repeating decimal places (such as when you divide by 3), at the end of the day, you're still going to be doing some kind of rounding off with BCDs as much as with fixed point binary. Yeah, there's maybe a little more work in using integer ops to do fixed points than there is with floating point, but it's going to be way faster than BCD calculations. If you're smart, you use a language or a compiler that allows you to hide most of that. For nearly all financial transactions, money is a fixed point value, and you can deal with it appropriately that way in decimal or binary arithmetic.

You'll find more references for what you're talking about Why PostgreSQL Instead of MySQL, and the associated Transactional DDL page goes over how it compares with Oracle--which has recently added a feature to address this area, so picking on it in this area is a bit out of date now.

You'll find more references for what you're talking about Why PostgreSQL Instead of MySQL, and the associated Transactional DDL page goes over how it compares with Oracle--which has recently added a feature to address this area, so picking on it in this area is a bit out of date now.

Can you elaborate on the 'correct' with emphasis?

Google says that both postgresql and mysql get hits from 'incorrect results'. Are you stating that mysql's bugs have gone unfixed while postgre's have not? Or what?

For fairness, I'm going by MySQL version 5.5, the development version.

The default storage engine will quietly ignore foreign key constraints and transactions. source for default engine, claim that MySQL parses and ignores for non-InnoDB

There are multiple "SQL Modes" that can alter correctness, source, but by default the DBMS doesn't try to validate input. It's pretty confusing what mode does what, and I don't care enough to figure it out, but MySQL's approach has always been Do What I Think You Mean, and if they set the new version to be ANSI compliant by default it'd break all the existing sites built on it.

(I'm claiming this qualifies as "not being correct" by virtue of the Information Principle. Granted, SQL itself violates it in many ways, but MySQL proved that you can do worse than SQL.)

PostgreSQL has a far more correct transaction model. In some ways, they're actually better than Oracle. (In Oracle, a DDL statement will start a new transaction, whereas PostgreSQL wraps DDL into a transaction.) For starters, there aren't multiple "storage engines" per table with different transactional behaviors. source, sort of.

Also, PostgreSQL, to my knowledge, correctly validates input. It's kind of hard to cite a source for this since there's just no FAQ entry "Q. How do I configure PostgreSQL to silently corrupt my data? A. You can't." But by the same token, they don't have any long-standing terrible design decisions that they have to maintain compatibility with.

It may not be as fast as MySQL, but it's certainly more robust and capable. If you look at the core of ORACLE's design (which is pretty damned good), you'll find that Postgresql has similar design principals.

When it comes to data loss, I'd rather the more robust database than the fastest one.