Slashdot Mirror

So you are saying you trust your data to a system that has an unbelievable list of gotchas -- you're saying that you prefer to try and keep all of these in mind when you write apps that use MySQL, and you are saying that you're not concerned about the data integrity issues brought up in this thread?

What company do you own, again?

MySQL's InnoDB offers the same level of data integrity as PgSQL...

There are quite a few differences, most succinctly described at http://sql-info.de/mysql/gotchas.html and http://sql-info.de/postgresql/postgres-gotchas.htm l

PostgreSQL is under a very clear license: BSD.
MySQL is under a very clear license, too: Whatever MySQL AB Feels Like Doing Right This Minute.

I do not need to repeat the earlier comments about the differences between what MySQL AB promises and what it delivers, but suffice it to say that those differences are comparable to any other sleazy proprietary software vendor.
--

There are quite a few differences, most succinctly described at http://sql-info.de/mysql/gotchas.html and http://sql-info.de/postgresql/postgres-gotchas.htm l

PostgreSQL is under a very clear license: BSD.
MySQL is under a very clear license, too: Whatever MySQL AB Feels Like Doing Right This Minute.

I do not need to repeat the earlier comments about the differences between what MySQL AB promises and what it delivers, but suffice it to say that those differences are comparable to any other sleazy proprietary software vendor.
--

Obligatory link

"This query is called a left outer join because the table mentioned on the left of the join operator will have each of its rows in the output at least once, whe reas the table on the right will only have those rows output that match some row of the left table. When outputting a left-table row for which there is no right -table match, empty (null) values are substituted for the right-table columns.
Exercise: There are also right outer joins and full outer joins. Try to find out what those do."

when there really should be:

"TODO: There are also right outer joins and full outer joins. FIXME: We MUST write more."

Not to mention the "RTFS" answers in "TFM" for questions very frequently asked by beginners:

"4.3) How do I get a list of tables or other things I can see in psql?"
"You can read the source code for psql in file pgsql/src/bin/psql/describe.c."

Other than that I would say that PostgreSQL is definitely the way to go today. Once you get used to reading the source code as documentation (it is actually very clean and properly commented, so that's not such a big deal), you will really love it. And you will have the most important thing: ACID features. I hope it helps, I wish you the best luck.

See also:

1. http://www.postgresql.org/
2. http://www.mysql.com/
3. http://en.wikipedia.org/wiki/MySQL
4. http://en.wikipedia.org/wiki/PostgreSQL
5. http://en.wikipedia.org/wiki/Firebird_(database_se rver)
6. http://en.wikipedia.org/wiki/Relational_database
7. http://en.wikipedia.org/wiki/Database_management_s ystem
8. http://en.wikipedia.org/wiki/ACID
9. http://en.wikipedia.org/wiki/Relational_model
10. http://en.wikipedia.org/wiki/SQL
11. http://en.wikipedia.org/wiki/Set_theory
12. http://en.wikipedia.org/wiki/Axiomatic_set_theory
13. http://en.wikipedia.org/wiki/Predicate_logic
14. http://www.glom.org/
15. http://www.servoy.com/
16. http://www.dotcomsolutionsinc.net/products/fmpro_m igrator/index.html
17. http://www.firebirdsql.org/

(Please forgive me if I repeat anything which has already been said. I started to write it as a first post but it took some time and I am sure that other

Watching people use mysql is like watching other people play video games. ie. If your watching someone play a video game and they aren't as good as your or absolutely pathetic, it can drive a person bonkers. I guess thats what postgresql users see when they see mysql users... people who don't know what they are doing or don't know any better.

It doesn't take a rocket scientist to see that postgresql is a better product, just look at the Gotcha's for Mysql and compare it to the gotcha's for postresql.

You can base you opinion of postgresql users on whatever criteria you want, but the people who know this stuff have already formed an opinion about you and its based on real criteria such as the above.

The funny thing is, you don't even know what postgres can do. Did you even evaluate your options before you started developing or did you just jump on the mysql train?

Call me a fanboy if you want but at least I can say I evaluated both systems.

Watching people use mysql is like watching other people play video games. ie. If your watching someone play a video game and they aren't as good as your or absolutely pathetic, it can drive a person bonkers. I guess thats what postgresql users see when they see mysql users... people who don't know what they are doing or don't know any better.

It doesn't take a rocket scientist to see that postgresql is a better product, just look at the Gotcha's for Mysql and compare it to the gotcha's for postresql.

You can base you opinion of postgresql users on whatever criteria you want, but the people who know this stuff have already formed an opinion about you and its based on real criteria such as the above.

The funny thing is, you don't even know what postgres can do. Did you even evaluate your options before you started developing or did you just jump on the mysql train?

Call me a fanboy if you want but at least I can say I evaluated both systems.

MySQL Gotchas

MySQL doesn't feature anything remotely like ANSI-standard SQL behavior. Migrating from MySQL to any other SQL DBMS is much harder than migrating between all the other major DBMS's put together. MySQL is the odd man out, here.

MySQL and PostgreSQL are really no different than debating linux distrubutions

No, the differences are quite consequential, much more like differences between Linux and (say) Windows.

Consider:

• PostgreSQL is developed as a community project. Some developers are sponsored by companies, much as is the case with most projects in the "open source community," but the results are essentially publicly owned.

  MySQL(tm) is none of the above; it is, altogether, a proprietary system closely held by a single small company, where all the developers are the employees of that company. There are, therefore, all the risks associated with the product being closely held.

• When you look at different Linux distributions, they are deeply similar because probably well over 90% of the source code is plucked from the very same "rivers" of projects. All the distributions use some version of Linux, GCC, GLIBC, Perl, Python, Apache, GNOME, KDE, and such.

  Distributions have persistent differences in the form of installation tools, but that's a small portion of the system.

• The technologies are really hugely different, as are the attitudes of the respective development "communities" towards relational database technology.

  The PostgreSQL team has a clear respect for the SQL standards, and prefer very much to conform to SQL standards. The MySQL implementors have had to be dragged, pretty much kicking and screaming, towards promising that they'll conform with ANSI some day. (Of course, that's likely to still have plenty of documented flaws.)

If anything pissed you off with MySQL

"8 bit clean"? Oh, now you've convinced me... So the fact that I have the inconvenience of running my data through escape_bytea() before storing it as a binary string is THE major reason why PostgreSQL shouldn't be used? That discounts anything else about what a DBMS should do?

Yeah, PostgreSQL doesn't support 'standard' data types, and MySQL does? I really hope someone isn't reading this thinking you are serious. (You are not serious, are you?). MySQL's support for real datatype constraints is so bad that it should be considered typeless.

The whole point of a serious DBMS like PostgreSQL is not to allow your data to do things it shouldn't. If you don't want constraints or real data integrity, then fine; Use MySQL. Just be aware that your application still has to reimplement half the things that the DBMS normally handles.

In my 8 years as an Oracle DBA I don't think i've ever seen a corrupt index. Saying that, I don't even know how you could force a index to get corrupted so I don't think were seeing all the info here.

There is alot of hype in the database market as is there with any other area such as OS preference. A good DBA, like a good software developer will pick the database that fits the needs. Saying that, usually DBA's (like anyone else) are under certain constraints from management but heres my take:

For:

Mission Critical Apps and large DB's: Oracle or DB2
Mid-Range apps/Mid-sized DB's: The above + SqlServer, PostgreSQL.
Small: SqlServer, PostgreSQL. (+ Oracle and DB2 if you like to toss around the $$).

I'd feel comfortable using PostgreSQL for upto and including mid-sized DB's. Currently I wouldn't use mySQL for anything until they fix their Gotcha's.

If you really and I mean really have faith in your developers and they have reviewed these gotcha's i'd consider MySQL but unfortunately, as every DBA knows this isn't always possible. It only takes one bad apple to mess everything up.

Of course there are many other factors to choosing a database but the core comes down to your employees and licensing. If all your DBA's have extensive training on Oracle then it doesn't make much sense to retrain them to use another DB just because it maybe a better fit. Also, if you have a server license for Oracle it doesn't make much sense to buy another so you can use DB2.

At our shop we have a mix of Oracle and SqlServer. But we do installs for DB2, Redbrick, informix, everything and anything under the sun.

Anyways, thats my 2 bits.

I can't figure out how a DBMS could have transaction support and be missing any features required to guarantee data integrity

MySQL Gotchas. Basically, it will silently convert datatypes and NULLs rather than throwing an error. Truly the VB of databases.

PostgreSQL needs more advertising. Most people don't even know that mySQL doesn't even have decent data integrity support, see http://sql-info.de/mysql/gotchas.html

...useless until you realize you have to connect to the DB from several applications written in several different languages for which you have either to reimplement your way to manipulate the data everywhere, or you have to put in a middle layer of some sort which is able to talk multiple languages (via CORBA, SOAP, plain XML RPC, custom protocol, whatever) and ensure that everyone is accessing data exclusively through it.

Reimplementing logic everywhere across different languages is usually a bad approach because it doubles the development and testing effort.

Middle layers are usually hard to get right the first time, much harder than using stored procedures and triggers, since the typical procedural language is not so at ease at manipulating relational data.

On MySQL: it has a somewhat bad reputation in the field because of the people abusing it: it's fast, it's free, it's easy to set up, but living with these gotchas is definitively too painful for developers more concerned about correctness than speed.

In the end: firing up Firebird/Oracle/PostgreSQL/SAPDB for simple data is plainly stupid, but often it is done anyways since they do a decent job even in that cases; firing up MySQL for your 30+ GB DB containing your whole network topology which is used by everyone for billing, service assurance, troubleshooting, network planning and whatever is stupid as well. MySQL AB knows that, and in fact it now proposes MaxDB (was: SAPDB) as well.

mySQL is very similar to other SQL dialects.

Um, no. Not even close. Check out all mysql's gotcha's and deviations from SQL standards:

http://sql-info.de/mysql/gotchas.html

PostgreSQL is not SQL compliant, either. It's much closer than MySQL, but it's not compliant. There's a few deviations here: PostgreSQL Gotchas. In addition to those, the quoting of SQL literals and identifiers is non-standard. It accepts \ as an escape character. (Try feeding \' to code that quotes it for PostgreSQL/MySQL and then feeds it to a database that quotes in the standard way. Or vice versa. It will break.)

To the best of my knowledge, there are no databases fully compliant to the SQL standard. But several are close enough under most circumstances.

Arguably there are different choices for different needs in web development (PostgreSQL, PHP, Java, etc.), but there is no argument that if you are planning on putting together a website, using MySQL and Perl that MySQL & Perl for the Web will aid immensely in that development.

Maybe so, but I still have trouble figuring out why MySQL is given so much credibility in the first place.

In the previous story about MySQL, I posted a comment asking what it actually did that other databases (including the also-free PostgreSQL) didn't do at least as well, or better. The main responses seemed to include:

• MySQL being the only DB supported for an application that someone wanted.
• People already being very familiar with MySQL's strange ways of doing things that are inconsistent with every other respected database, not to mention SQL standards.
• No other free databases having reliable Windows builds. (A Windows build of Postgres is on the way, but not yet fully complete.)
• ISP's only providing a MySQL server.
• Simply not knowing anything else due to past experience.

The Windows build issue seems quite reasonable, but the other reasons imply that the main reason MySQL is so popular is simply due to lock-in. People use it because they have to, or because they're not familiar with the alternatives --- not necessarily because it's actually better for the task-at-hand.

Perhaps MySQL is such a common name that people haven't heard of better alternatives out there. Presumably the book that this story reviews, which gives it even more publicity, is yet another reason that someone might consider MySQL without even thinking about alternatives.

Can anyone tell me if I've missed anything, though? Besides the typical lock-in reasons for using MySQL, does it actually do anything better than other databases as any sort of killer feature?

If not, and if you're looking to start learning about a database and actually have a choice, it seems that you're much better off looking at an alternative database.... whether it be a free one such as Postgres, or one of the big ones such as Oracle or SQL Server. At the very least, you'd get a more reliable database than MySQL, a more portable database than MySQL, and even postgres (just as free) offers a wealth of additional -- often useful and important -- features such as stored procedures and more complete data integrity. You'll probably also become much more familiar with correct SQL syntax ... for what it's worth.

My god, you can't even do subqueries? What the hell? No views?!

Visit MySQL Gotchas for a list of the stuff you don't hear about mySQL around here.

MySQL is popular because it's easy to learn because it doesn't have all those "complicated" advanced features real databases have, so people who learn MySQL suddenly think they've become DB admin experts. Then they try Oracle or PostgreSQL or one of the other big boys, get confused and overwhelmed, and fall back on MySQL because it's easier for them despite having reduced functionality, often without them knowing that if they learned a real database they could do some incredibly powerful things with the braindead SQL they write to get MySQL to work. I've had to translate some Oracle single queries into as many as four for MySQL (!).

Seriously, that's why.

You may be right that the people who want features like subqueries, views or stored procedures are not providing reasons but only whining. On the other hand, you are guilty of the same thing with blanket statements like 'Stored procedures and similar features are just bloat, and gain you no real advantage' - many programmers working with more advanced RDBMSes know otherwise. BTW, I also disagree with your assertion about subqueries being slow: you have to take care, yes, but like most things they are a very useful tool in the right hands and most simple uses of subqueries are not slow (at least on the databases I have most used, Oracle and Sybase).

I'm interested to know: have you ever run into the problems mentioned in MySQL Gotchas? Or are these deviations from the ANSI standards something that doesn't matter in practice.

The reason for its success: Worse is better.

What you say about disregard for SQL standards is true, see MySQL Gotchas. Doing the wrong thing is not so bad, it's *silently* doing the wrong thing that you absoultely do not want in a database system. See also Why not MySQL, which is now rather dated (MySQL has grown some features since), but is a good introduction to what a database should do.

Note also that anyone can write a database system with complete transactional integrity: you simply lock the whole database for every single operation and run only one query or update at a time, one after the other. The challenge is in getting the semantics of serialized database access but with good performance. This is what schemes like row-level locking and multi-version concurrency are for.

If application bigotry keeps you from choosing the right tool for a job, you will be a less valuable resource to those who employ you.

Pardon my ignorance, but what is it exactly that MySQL is good at that Postgresql isn't at least equal or better at? I'm all for using the right tool for the right job, but every time I've used at MySQL I've frequently encountered all sorts of crazy problems with no killer features to justify the change, that aren't already provided by both postgres and other databases. Maybe it's my application bigotry speaking, but I honestly can't see how MySQL is better at anything.

The only things I can think of are the familiarity aspect, for people who are already very knowledgable about MySQL not wanting to switch, and possibly some minor issues with moving database files around on the underlying file system.

In a nutshell, MySql is free. Is it great? Hell no, but it's free. The only deep understanding of human nature or the DB marketplace one needs to comprehend here is that given the choice between something great and expensive vs. something mediocre and free, the overwhelming majority will go for free.

It's not that simple. If it were, everyone would be using PostgreSQL instead of MySQL. It's free, and it's better.

I think the big reason is marketing. MySQL people are really good at that. The PostgreSQL people are learning, but there's still a ways to go. Also, PostgreSQL doesn't work natively on Windows; that's one of the features they hope to have Real Soon Now.

There's also a huge misconception that MySQL is much easier to install than PostgreSQL. The process seems exactly the same to me. I don't understand at all why people think this.

It has no row locking, no transaction support, and minimal cross-platform compatibility. But, it's free and it works more or less ok on Linux

Before all of the MySQL zealots jump all over you, I should point out that MySQL does have transaction support (with the proper table type, and so long as it's built in, and you're using a current enough version, and you made sure to tag your tables with the right syntax to make sure they are of the right table type, etc), and does cross-platform well enough (better than PostgreSQL, as much as I love that engine). I don't know about row-level locking, but I'm sure it can't be far now.

The biggest problem with MySQL is inconsistencies in both the engine itself and the development community. For years, the MySQL community told developers, "You don't need [transactions | foreign keys | triggers | stored procedures | subselects | ...]! You can work around those limitations in your application code and be better off for it!" Only they then go and implement those features that developers "don't need". That would be fine, except that the implementation of the features often leaves something to be desired, and have too many quirks. For instance, I mentioned above that you can only get transactions and referential integrity if you're using the correct table type. However, that table type is not the default, and even if you do create your tables properly to take advantage of those features, MySQL doesn't fail if the table type is not supported, choosing instead to make your table an inferior type. Now you think you have transactional support and referential integrity because your database built just fine, but what you don't know is that your hosting provider didn't build that table type into their deployment of MySQL, and you really don't have those features at all. Good luck trying to figure out why your data is corrupted even though you had proper transactioning in your code.

MySQL has other problems as well. For example, if I want a column to be NOT NULL, I want any code that tries to insert a NULL into that column to fail. I don't want the engine to try to pick some default value for me. If I wanted a default, I would've added a default. That's why default constraints exist. By that same token, if I want a column to allow NULLs, I want to be able to put a NULL in the column. I don't want the current date/time instead of a NULL. If I define a column as auto-incrementing, I want to get an error if I try to insert something into that column. I don't want it to quietly succeed.

There's plenty more on that page, though most MySQL apologists will tell you either that the problem is fixed (which is fine, except that being fixed in the latest beta is far different from being fixed in the most widely-deployed versions from different hosting providers and such), or that it "will be in the next release". These are the same people that will tell you that stored procedures are unecessary, and anybody that thinks they are is stupid (or they'll tell you that the performance gains from being able to compile your SQL code is negligible, while completely ignoring all of the other benefits of stored procedures ... *COUGH*security*COUGH* ...). And so on. MySQL is fine for what it does, but it's not the end-all of SQL software. Far from it.

Good to see MySQL develops so fast and its press releases are already hyped enough.

If the MySQL development team did clustering, perhaps now they could consider implementing stuff from numerous wishlists, mainly from here and here...

I had a payment processing app on MySQL because of a shared hosting environment that only supported MySQL.

I moved it to my own server and ported to PostgreSQL for several reasons. First, I was working with several timezones, and MySQL just drove me crazy there. Maybe I missed something, I don't know, but it seemed simple enough in PostgreSQL. MySQL would not report all errors to me, so I would assume that something was working as expected, like when I did "SELECT ... WHERE orderdate<'2003-06-06 01:02:03 PST'", when in reality it would just ignore my timezone and give me whatever rows it felt like. Similar case with other "minor" errors like a wrong date (MySQL thinks that february 31st exists), which would just go silently through. I think there is also some weirdness about how it handles strings.

I ported to PostgreSQL in no time (it had simple database access) and had exactly 0 problems after that. Everything worked as expected, or gave me a big error so I could correct the problem before it became a real problem.

Bottom line: I trust PostgreSQL. With MySQL, I have to trust, but verify.

But yeah, MySQL does work. I imagine if you really know how it works in detail you can avoid the gotchas.

Postgresql is underdocumented, the MySQL online documentation simply excels.

Complete and utter bullshit. How is this for documentation? There are also excellent books about it.

There is no readily available workforce that has actual Postgresql knowledge. There are on the other hand buttloads of people available that can drive average sized MySQL installations for cheap money.

That's a circular argument: everybody uses MySQL because everyone else does. (I can name a certain OS that benefits from this situation...) A good DBA would have no problem picking up PostgreSQL in a matter of days. I don't care about trained monkeys.

There is no readily available workforce that has actual Postgresql knowledge. There are on the other hand buttloads of people available that can drive average sized MySQL installations for cheap money.

Again bullshit. PostgreSQL supports multiple databases per server very well, including separate access controls for each db.

Postgresql replication is regarded mostly experimental and is not properly integrated with the server. In larger MySQL deployments, replication is often used for load sharing (direct read only queries against any replica), and for backups.

Replication (in both MySQL and PostgreSQL) is mostly useless since it is asynchronous. That is, when you commit a transaction you can not be sure if/when it gets propagated to the slaves. Therefore, if you read from a slave you can never be sure that it's up to date. I'll grant you that there are certain situations where this can be tolerated, but for high availability mission critical sites, it's useless. For that you need distributed transactions. The only open source DB that supports them is firebird.

BTW, I'm glad you mentioned backups. PostgreSQL , just like any real database, can do on-line backups. However, to back up MySQL, you need to read-lock all the tables! The only way to get around that is by setting up replication and backing up the slave.

Postgresql already has many features MySQL either just got with 4.1 or is planned to get in 5.x. That is useless, though, if you do not need these features, but need to deploy in a hosted standard environment, relying on the available workforce.

Yeah, I'm sure you don't need transactions, subselects, triggers, stored procedures, or even *gasp* correct and predictable behaviour.

But you are right about one thing: everybody uses MySQL because everybody else does.

Last I checked (which probably has changed somewhat by now)...

MySQL does not support views, stored procedures, transactions (InnoDB does, but this is an additional product) and a bunch of other developer's friends. Check out the comparison at www.sql-info.de.

I also seem to remember replication was superior on PgSQL. Feel free to correct me.

MySQL's big draw was simplicity and speed. Not sure if that's really relevant, in the big picture, since PG has sped up quite a bit recently, and adding InnoDB kills the speed advantage, from what I've heard.

Also check this awesome comparison. This guy is amazing: http://www.phpbuilder.com/columns/tim20000705.php3

Personally, as a DBA, I don't like mySql because of the numerous gotcha's it has unlike postgreSql. That speaks for itself... but hey, if you write bugfree code and trust that others do as well, then go ahead, use it. BTW> I'm a fan of postgreSQL, I wouldn't hesitate to recommend that if $$$ are a concern.

Personally, as a DBA, I don't like mySql because of the numerous gotcha's it has unlike postgreSql. That speaks for itself... but hey, if you write bugfree code and trust that others do as well, then go ahead, use it. BTW> I'm a fan of postgreSQL, I wouldn't hesitate to recommend that if $$$ are a concern.

...now after this, it should have given you a message like:
"Query OK, 1 row affected"

Seems to me that the data was a collection of square pegs to round holes, but MySQL never even dropped a warning.

So let's check out that table again:

SELECT * FROM test;

1 row with the following is returned.

id: 1
num1: 2147483647
num2: 0
num3: 0
price: 999.99
code: ABCDEFGH

Now stop. Take another look at the table definition. Take another look at the inserted data. Take another look at the output. Take another look at what has been stored in your database. Let's sum up: your primary key (your lookup key!) is not what you expected, the numbers are all different from what you entered, the price does not conform to your data schema (should be a maximum of 99.99), and your character string has been truncated...ALL WITHOUT AN ERROR OR WARNING.

More examples at MySQL Gotchas. All of this in MySQL v4.0 and above. None of this crap happens in Firebird 1.5, PostgreSQL 7.x, or any popular closed source relational database.

...and it is crap. You have crap data in your database, and MySQL never let you know. For those of you out there who never ever write code with bugs, there's no problem; Go on ahead using MySQL. (Then again, you're in high demand for senior, very well paying jobs using Oracle or DB2 in Fortune 100 companies if that's the case.) For all the other folks out there (which includes everyone out there doing web development with dynamically typed languages like Perl and PHP), MySQL will happily insert crap data.

And yes, there's a PostgreSQL Gotchas page. Tables are lowercase by default, and it requires the "AS" keyword for column aliases. Look at that list for PostgreSQL. Look at that above example. Can someone say with a straight face that these lists are comparable? Can someone say with a straight face that they want to explain to the computer-phobe why they got 2147483647 in their data? Can someone say with a straight face to their boss that these errors are acceptable in a production environment?

...now after this, it should have given you a message like:
"Query OK, 1 row affected"

Seems to me that the data was a collection of square pegs to round holes, but MySQL never even dropped a warning.

So let's check out that table again:

SELECT * FROM test;

1 row with the following is returned.

id: 1
num1: 2147483647
num2: 0
num3: 0
price: 999.99
code: ABCDEFGH

Now stop. Take another look at the table definition. Take another look at the inserted data. Take another look at the output. Take another look at what has been stored in your database. Let's sum up: your primary key (your lookup key!) is not what you expected, the numbers are all different from what you entered, the price does not conform to your data schema (should be a maximum of 99.99), and your character string has been truncated...ALL WITHOUT AN ERROR OR WARNING.

More examples at MySQL Gotchas. All of this in MySQL v4.0 and above. None of this crap happens in Firebird 1.5, PostgreSQL 7.x, or any popular closed source relational database.

...and it is crap. You have crap data in your database, and MySQL never let you know. For those of you out there who never ever write code with bugs, there's no problem; Go on ahead using MySQL. (Then again, you're in high demand for senior, very well paying jobs using Oracle or DB2 in Fortune 100 companies if that's the case.) For all the other folks out there (which includes everyone out there doing web development with dynamically typed languages like Perl and PHP), MySQL will happily insert crap data.

And yes, there's a PostgreSQL Gotchas page. Tables are lowercase by default, and it requires the "AS" keyword for column aliases. Look at that list for PostgreSQL. Look at that above example. Can someone say with a straight face that these lists are comparable? Can someone say with a straight face that they want to explain to the computer-phobe why they got 2147483647 in their data? Can someone say with a straight face to their boss that these errors are acceptable in a production environment?

MySQL is listed with OVER 20.

It's not about being a postgres fanboy/troll.. reality is that MySQL DOES NOT have features comparable to Oracle/PostgreSQL/SQL Server. When are you going to understand this??

As a DBD (db developer) I CAN'T use MySQL - it's feature set is too WEAK. MySQL is starting to get some of these features now and good for them but the argument was always about the feature set.. fuck some of you are dimwits...

And yes I've just fed a troll but fuck it, now im all pissed off and want another coffee..

Look at your own gotchas before laughing at others!

another interessting read is here.

Now finally MySQL will look good on the client. Too damn bad all that GUI work is hobbled by such a crap datastore. I honestly wonder how the GUI will react to all of the silent "best guess" errors. ...must do a lot of data display refreshes.

http://sql-info.de/mysql/gotchas.html

It's like when Windows Millenium Edition was released. Sure it was pretty, but what lay beneath was atrocious.

I'm going to respond one final time and then I give up.

This is not a religious argument, and I am sick to death of people trying to portray it as such.

Just because the MySQL daemon process does not crash does not mean that MySQL is a reliable datastore. I simply do not trust MySQL to reliably store data, since it performs so many silent modifications to both the table schema and to input data itself. These design flaws are well documented in the MySQL Gotchas page. You claim that you've used MySQL for several years without incident. I've also used it, both 3.23 and 4.0.1x, for over a year and have had nothing but problems with it. (As an aside, I don't know how you're claiming that PostgreSQL has had stability problems "until recently" -- I've run several 7.1, 7.2, 7.3 and 7.4 databases for about 4 years with no stability or performnce problems at all.)

If a DBMS can't do exactly what I instructed it to do, it should raise an error and abort. It should not silently modify data or make a random guess about what to do. This is not desirable behavior. Frankly, this is a lesson that every programmer is taught in their first compsci class. The problem is that MySQL wants to be newbie-friendly, so it silently passes errors. This statement does not make me some "purist" who's out of touch with the real world, it's just how SQL is designed.

SQL is not HTML and it should not be parsed as such. In HTML, if your browser comes across a tag that it doesn't understand, then it skips it, and there's no harm done. The HTML language is designed to behave this way. SQL is not. In SQL, if your DBMS comes across a SQL command that it cannot handle, it must immediately abort. The problem is that MySQL doesn't. So if you're using MyISAM tables, and you issue a START TRANSACTION command, MySQL will happily print "OK" and continue on its merry way. Same if you try to define a foreign key, etc. This is not desirable behavior; it is clearly a design flaw. Anal-retentive error checking is absolutely appropriate for a DBMS.

When I read "MySQL attempts to make reasonable assumptions in situations where different clients may have varying ways of making a query", I nearly fell out of my chair. MySQL's handling of default values and NULLs is so incorrect that it's not even funny. MySQL seems confused about the value 0, the empty string "", the current timestamp and a NULL (which is not a value). Again, see the MySQL Gotchas page for examples. Its habit of (silently and automatically) creating default values for every column effectively "castrates" any NOT NULL constraint. This behavior also makes writing portable applications very difficult - since no other DBMS takes such liberties with its inputs. Of course, other DBMS also don't lie about performing operations...

I'll end with one final example of silent error passing in MySQL 4. Say you're try to create an InnoDB table. If you have "skip-innodb" enabled in my.cnf, then MySQL 4 can't create an InnoDB table. But, if you do a CREATE TABLE foo(blah) TYPE=InnoDB; MySQL won't bother to print an error message. It won't tell you "Hey, I can't create an InnoDB table, b/c you disabled support." No, it will instead print "OK" and then go and create a MyISAM table. So, you asked to get a table with one set of behaviors, but you ended up getting one with entirely different characteristics. I encountered this bug at work a few months ago on a MySQL database I inherited from a previous "DBA": I started wondering why certain operations weren't failing, and eventually traced down the problem. (This, by the way, is yet more evidence of MySQL's questionable design of having different table types which behave differently. The hallmark of relational databases was supposed to be independence from physical storage methods; MySQL has gone and reintroduced these dependencies).

You started this thread by saying that you question what niggling problems remain in PostgreSQL because some random Slashdot post mad

Funny that you seem so intent on bashing these mythical PostgreSQL advocates, yet you ignore all of the pure BS that's been spewn from MySQL advocates and from MySQL.com itself. They have posted clearly skewed benchmarks between their product and PG and have outright lied in claiming that their database doesn't need "high-end" features like transactions, referential integrity, validity checking on inputs, etc.

Secondly, I wouldn't say that MySQL is making "fantastic progress." Yes, v4 is better that 3.23, but a lot of the new features (transaction, foreign keys, etc) are half-assed implementations and are trivially easy to disable or bypass. This is in addition to its numerous design flaws, which are well documented on the MySQL Gotchas page. Yes, every program has bugs, but the items listed on MySQL Gotchas go beyond mere bugs - they are fundamental design flaws. It is exactly these flaws which show no sign of being fixed.

Finally, I have to say that perhaps the biggest disservice that MySQL AB (the company) has done to the database commuity as a whole is to dumb it down. They have created a mindset where raw speed is seen as the most important factor in choosing a DBMS, and further, that the DBMS should be a dumb, raw datastore, with any data processing (no matter how basic) done in the application. They have eschewed compliance with the SQL standards. They have managed to convince a large number of developers that anything beyond SELECT, INSERT, DELETE and UPDATE are "high-end" features. This is simply not true. Foreign keys, referential integrity constraints, CHECK constraints, datatypes that work (like a good DATE datatype) matter.

Quirkiness is a major problem with MySQL. Once you get started with non-standard implementation, you travel down a path from which it is difficult to return.

You could have just done this.

One of the biggest problems with MySQL that so many people complain about is that the entire design philosophy is not one that supports data integrity. Take a look at the list of MySQL Gotchas for starters.

The reason that it's satisfactory for slashdot is the same reason that it became popular in the first place. It was one of the first freely available database servers, and it had particularly fast benchmark results for situations that required lots of selects and not many updates. (I might be slightly wrong about the details, so someone correct me if necessary.) The fast-select advantage made it a popular option for websites a few years ago, because they involve just that. Lots of page-views (selects) and not many updates.

On the other hand, the integrity aspect of MySQL makes it a pain to code for. The MySQL credo seems to be that if input doesn't make sense, then try to guess what was meant and don't report it. (eg. Inserting a null instead of reporting an error.) Furthermore, the MySQL parser recognises certain parts of SQL syntax that are ignored, and (again) not reported. Instead, it just doesn't do anything and pretends that it all worked.

So instead of being able to rely on constraints set in the database, as can be done with nearly any other well-used database, it's necessary to put large amounts of integrity-checking code for things as simple as making sure that dates are the correct format. In some ways it's more like a half-built SQL interface to a regular file system than a database, with features for data integrity hacked on here and there if you know how to use them and always use them correctly.

In slashdot's case, don't be surprised if a random comment goes missing every now and again, because the integrity support just isn't there without complicated overhead work that induces possible mistakes. Slashdot can get away with losing bits and pieces of data, but that's not usually the case. If I say that I want to put some data in the database and that it must meet specific rules, it should either put it in or result in an error. MySQL doesn't do this reliably.

MySQL now seems to be living only on it's fast reputation that it had in the past, driven by people who've heard that it's good and it's fast, but don't know the details. By now, other free databases (postgresql in particular) have caught up a lot, and should be preferable in most cases if you're starting from scratch.

• 1. General SQL
  • 1.1 NULL, or when NULL IS NOT NULL
  • 1.2 AUTO_INCREMENT
  • 1.3 ENUM
  • 1.4 Case sensitivity in CHAR / VARCHAR fields
  • 1.5 Variable length CHAR fields
  • 1.6 VARCHAR's trailing blank allergy
  • 1.7 DEFAULT NOW()
  • 1.8 INSERT INTO ... SELECT ...
  • 1.9 Comments beginning with --
  • 1.10 UNION and literal values
  • 1.11 Division by zero
  • 1.12 'concatenation' || 'or'
  • 1.13 What goes in - isn't (always) what comes out
  • 1.14 February 31st

• 2. Database Definition
  • 2.1 Silent Column Specification Changes
  • 2.2 Implicit primary key
  • 2.3 Supported syntax, unsupported feature
  • 2.4 Whoops, no InnoDB table support

• 3. Foreign Keys and Referential Integrity
  • 3.1 ALTER TABLE ... SET NOT NULL
  • 3.2 Ignoring constraints
  • 3.3 ERROR 1005
  • 3.4 ON UPDATE CASCADE / SET NULL

• 4. Transactions and InnoDB tables
  • 4.1 Transactions on mixed table types
  • 4.2 Altering InnoDB tables

Don't read this: Slashdot lameness messages are very annoying when you have posted a legitimate comment: Your comment has too few characters per line (currently 18.5). Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted. Your comment violated the "poster-comment" compre55ion filter. Try less whi7espace and/or less repetition. Comment aborted. Your commen7 has too few characters per 1ine. Your comment has too few characters per line (currently 18.5). Your comment violated the "poster-comment" compre66ion filter. Try less whitespace and/or less repetition. Comment aborted. Your comment has too few characters per line (currently 18.5). Your comment has too few characters per line.

Now it says: Your commen7 has too few characters per line (currently 33.7). However, I didn't change the number of lines.

# Important Stuff: Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjust

• 1. General SQL
  • 1.1 NULL, or when NULL IS NOT NULL
  • 1.2 AUTO_INCREMENT
  • 1.3 ENUM
  • 1.4 Case sensitivity in CHAR / VARCHAR fields
  • 1.5 Variable length CHAR fields
  • 1.6 VARCHAR's trailing blank allergy
  • 1.7 DEFAULT NOW()
  • 1.8 INSERT INTO ... SELECT ...
  • 1.9 Comments beginning with --
  • 1.10 UNION and literal values
  • 1.11 Division by zero
  • 1.12 'concatenation' || 'or'
  • 1.13 What goes in - isn't (always) what comes out
  • 1.14 February 31st

• 2. Database Definition
  • 2.1 Silent Column Specification Changes
  • 2.2 Implicit primary key
  • 2.3 Supported syntax, unsupported feature
  • 2.4 Whoops, no InnoDB table support

• 3. Foreign Keys and Referential Integrity
  • 3.1 ALTER TABLE ... SET NOT NULL
  • 3.2 Ignoring constraints
  • 3.3 ERROR 1005
  • 3.4 ON UPDATE CASCADE / SET NULL

• 4. Transactions and InnoDB tables
  • 4.1 Transactions on mixed table types
  • 4.2 Altering InnoDB tables

Don't read this: Slashdot lameness messages are very annoying when you have posted a legitimate comment: Your comment has too few characters per line (currently 18.5). Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted. Your comment violated the "poster-comment" compre55ion filter. Try less whi7espace and/or less repetition. Comment aborted. Your commen7 has too few characters per 1ine. Your comment has too few characters per line (currently 18.5). Your comment violated the "poster-comment" compre66ion filter. Try less whitespace and/or less repetition. Comment aborted. Your comment has too few characters per line (currently 18.5). Your comment has too few characters per line.

Now it says: Your commen7 has too few characters per line (currently 33.7). However, I didn't change the number of lines.

# Important Stuff: Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjust

• 1. General SQL
  • 1.1 NULL, or when NULL IS NOT NULL
  • 1.2 AUTO_INCREMENT
  • 1.3 ENUM
  • 1.4 Case sensitivity in CHAR / VARCHAR fields
  • 1.5 Variable length CHAR fields
  • 1.6 VARCHAR's trailing blank allergy
  • 1.7 DEFAULT NOW()
  • 1.8 INSERT INTO ... SELECT ...
  • 1.9 Comments beginning with --
  • 1.10 UNION and literal values
  • 1.11 Division by zero
  • 1.12 'concatenation' || 'or'
  • 1.13 What goes in - isn't (always) what comes out
  • 1.14 February 31st

• 2. Database Definition
  • 2.1 Silent Column Specification Changes
  • 2.2 Implicit primary key
  • 2.3 Supported syntax, unsupported feature
  • 2.4 Whoops, no InnoDB table support

• 3. Foreign Keys and Referential Integrity
  • 3.1 ALTER TABLE ... SET NOT NULL
  • 3.2 Ignoring constraints
  • 3.3 ERROR 1005
  • 3.4 ON UPDATE CASCADE / SET NULL

• 4. Transactions and InnoDB tables
  • 4.1 Transactions on mixed table types
  • 4.2 Altering InnoDB tables

Don't read this: Slashdot lameness messages are very annoying when you have posted a legitimate comment: Your comment has too few characters per line (currently 18.5). Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted. Your comment violated the "poster-comment" compre55ion filter. Try less whi7espace and/or less repetition. Comment aborted. Your commen7 has too few characters per 1ine. Your comment has too few characters per line (currently 18.5). Your comment violated the "poster-comment" compre66ion filter. Try less whitespace and/or less repetition. Comment aborted. Your comment has too few characters per line (currently 18.5). Your comment has too few characters per line.

Now it says: Your commen7 has too few characters per line (currently 33.7). However, I didn't change the number of lines.

# Important Stuff: Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjust

• 1. General SQL
  • 1.1 NULL, or when NULL IS NOT NULL
  • 1.2 AUTO_INCREMENT
  • 1.3 ENUM
  • 1.4 Case sensitivity in CHAR / VARCHAR fields
  • 1.5 Variable length CHAR fields
  • 1.6 VARCHAR's trailing blank allergy
  • 1.7 DEFAULT NOW()
  • 1.8 INSERT INTO ... SELECT ...
  • 1.9 Comments beginning with --
  • 1.10 UNION and literal values
  • 1.11 Division by zero
  • 1.12 'concatenation' || 'or'
  • 1.13 What goes in - isn't (always) what comes out
  • 1.14 February 31st

• 2. Database Definition
  • 2.1 Silent Column Specification Changes
  • 2.2 Implicit primary key
  • 2.3 Supported syntax, unsupported feature
  • 2.4 Whoops, no InnoDB table support

• 3. Foreign Keys and Referential Integrity
  • 3.1 ALTER TABLE ... SET NOT NULL
  • 3.2 Ignoring constraints
  • 3.3 ERROR 1005
  • 3.4 ON UPDATE CASCADE / SET NULL

• 4. Transactions and InnoDB tables
  • 4.1 Transactions on mixed table types
  • 4.2 Altering InnoDB tables

Don't read this: Slashdot lameness messages are very annoying when you have posted a legitimate comment: Your comment has too few characters per line (currently 18.5). Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted. Your comment violated the "poster-comment" compre55ion filter. Try less whi7espace and/or less repetition. Comment aborted. Your commen7 has too few characters per 1ine. Your comment has too few characters per line (currently 18.5). Your comment violated the "poster-comment" compre66ion filter. Try less whitespace and/or less repetition. Comment aborted. Your comment has too few characters per line (currently 18.5). Your comment has too few characters per line.

Now it says: Your commen7 has too few characters per line (currently 33.7). However, I didn't change the number of lines.

# Important Stuff: Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjust

• 1. General SQL
  • 1.1 NULL, or when NULL IS NOT NULL
  • 1.2 AUTO_INCREMENT
  • 1.3 ENUM
  • 1.4 Case sensitivity in CHAR / VARCHAR fields
  • 1.5 Variable length CHAR fields
  • 1.6 VARCHAR's trailing blank allergy
  • 1.7 DEFAULT NOW()
  • 1.8 INSERT INTO ... SELECT ...
  • 1.9 Comments beginning with --
  • 1.10 UNION and literal values
  • 1.11 Division by zero
  • 1.12 'concatenation' || 'or'
  • 1.13 What goes in - isn't (always) what comes out
  • 1.14 February 31st

• 2. Database Definition
  • 2.1 Silent Column Specification Changes
  • 2.2 Implicit primary key
  • 2.3 Supported syntax, unsupported feature
  • 2.4 Whoops, no InnoDB table support

• 3. Foreign Keys and Referential Integrity
  • 3.1 ALTER TABLE ... SET NOT NULL
  • 3.2 Ignoring constraints
  • 3.3 ERROR 1005
  • 3.4 ON UPDATE CASCADE / SET NULL

• 4. Transactions and InnoDB tables
  • 4.1 Transactions on mixed table types
  • 4.2 Altering InnoDB tables

Don't read this: Slashdot lameness messages are very annoying when you have posted a legitimate comment: Your comment has too few characters per line (currently 18.5). Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted. Your comment violated the "poster-comment" compre55ion filter. Try less whi7espace and/or less repetition. Comment aborted. Your commen7 has too few characters per 1ine. Your comment has too few characters per line (currently 18.5). Your comment violated the "poster-comment" compre66ion filter. Try less whitespace and/or less repetition. Comment aborted. Your comment has too few characters per line (currently 18.5). Your comment has too few characters per line.

Now it says: Your commen7 has too few characters per line (currently 33.7). However, I didn't change the number of lines.

# Important Stuff: Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjust

• 1. General SQL
  • 1.1 NULL, or when NULL IS NOT NULL
  • 1.2 AUTO_INCREMENT
  • 1.3 ENUM
  • 1.4 Case sensitivity in CHAR / VARCHAR fields
  • 1.5 Variable length CHAR fields
  • 1.6 VARCHAR's trailing blank allergy
  • 1.7 DEFAULT NOW()
  • 1.8 INSERT INTO ... SELECT ...
  • 1.9 Comments beginning with --
  • 1.10 UNION and literal values
  • 1.11 Division by zero
  • 1.12 'concatenation' || 'or'
  • 1.13 What goes in - isn't (always) what comes out
  • 1.14 February 31st

• 2. Database Definition
  • 2.1 Silent Column Specification Changes
  • 2.2 Implicit primary key
  • 2.3 Supported syntax, unsupported feature
  • 2.4 Whoops, no InnoDB table support

• 3. Foreign Keys and Referential Integrity
  • 3.1 ALTER TABLE ... SET NOT NULL
  • 3.2 Ignoring constraints
  • 3.3 ERROR 1005
  • 3.4 ON UPDATE CASCADE / SET NULL

• 4. Transactions and InnoDB tables
  • 4.1 Transactions on mixed table types
  • 4.2 Altering InnoDB tables

Don't read this: Slashdot lameness messages are very annoying when you have posted a legitimate comment: Your comment has too few characters per line (currently 18.5). Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted. Your comment violated the "poster-comment" compre55ion filter. Try less whi7espace and/or less repetition. Comment aborted. Your commen7 has too few characters per 1ine. Your comment has too few characters per line (currently 18.5). Your comment violated the "poster-comment" compre66ion filter. Try less whitespace and/or less repetition. Comment aborted. Your comment has too few characters per line (currently 18.5). Your comment has too few characters per line.

Now it says: Your commen7 has too few characters per line (currently 33.7). However, I didn't change the number of lines.

# Important Stuff: Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjust

• 1. General SQL
  • 1.1 NULL, or when NULL IS NOT NULL
  • 1.2 AUTO_INCREMENT
  • 1.3 ENUM
  • 1.4 Case sensitivity in CHAR / VARCHAR fields
  • 1.5 Variable length CHAR fields
  • 1.6 VARCHAR's trailing blank allergy
  • 1.7 DEFAULT NOW()
  • 1.8 INSERT INTO ... SELECT ...
  • 1.9 Comments beginning with --
  • 1.10 UNION and literal values
  • 1.11 Division by zero
  • 1.12 'concatenation' || 'or'
  • 1.13 What goes in - isn't (always) what comes out
  • 1.14 February 31st

• 2. Database Definition
  • 2.1 Silent Column Specification Changes
  • 2.2 Implicit primary key
  • 2.3 Supported syntax, unsupported feature
  • 2.4 Whoops, no InnoDB table support

• 3. Foreign Keys and Referential Integrity
  • 3.1 ALTER TABLE ... SET NOT NULL
  • 3.2 Ignoring constraints
  • 3.3 ERROR 1005
  • 3.4 ON UPDATE CASCADE / SET NULL

• 4. Transactions and InnoDB tables
  • 4.1 Transactions on mixed table types
  • 4.2 Altering InnoDB tables

Don't read this: Slashdot lameness messages are very annoying when you have posted a legitimate comment: Your comment has too few characters per line (currently 18.5). Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted. Your comment violated the "poster-comment" compre55ion filter. Try less whi7espace and/or less repetition. Comment aborted. Your commen7 has too few characters per 1ine. Your comment has too few characters per line (currently 18.5). Your comment violated the "poster-comment" compre66ion filter. Try less whitespace and/or less repetition. Comment aborted. Your comment has too few characters per line (currently 18.5). Your comment has too few characters per line.

Now it says: Your commen7 has too few characters per line (currently 33.7). However, I didn't change the number of lines.

# Important Stuff: Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjust

• 1. General SQL
  • 1.1 NULL, or when NULL IS NOT NULL
  • 1.2 AUTO_INCREMENT
  • 1.3 ENUM
  • 1.4 Case sensitivity in CHAR / VARCHAR fields
  • 1.5 Variable length CHAR fields
  • 1.6 VARCHAR's trailing blank allergy
  • 1.7 DEFAULT NOW()
  • 1.8 INSERT INTO ... SELECT ...
  • 1.9 Comments beginning with --
  • 1.10 UNION and literal values
  • 1.11 Division by zero
  • 1.12 'concatenation' || 'or'
  • 1.13 What goes in - isn't (always) what comes out
  • 1.14 February 31st

• 2. Database Definition
  • 2.1 Silent Column Specification Changes
  • 2.2 Implicit primary key
  • 2.3 Supported syntax, unsupported feature
  • 2.4 Whoops, no InnoDB table support

• 3. Foreign Keys and Referential Integrity
  • 3.1 ALTER TABLE ... SET NOT NULL
  • 3.2 Ignoring constraints
  • 3.3 ERROR 1005
  • 3.4 ON UPDATE CASCADE / SET NULL

• 4. Transactions and InnoDB tables
  • 4.1 Transactions on mixed table types
  • 4.2 Altering InnoDB tables

Don't read this: Slashdot lameness messages are very annoying when you have posted a legitimate comment: Your comment has too few characters per line (currently 18.5). Your comment violated the "postercomment" compression filter. Try less whitespace and/or less repetition. Comment aborted. Your comment violated the "poster-comment" compre55ion filter. Try less whi7espace and/or less repetition. Comment aborted. Your commen7 has too few characters per 1ine. Your comment has too few characters per line (currently 18.5). Your comment violated the "poster-comment" compre66ion filter. Try less whitespace and/or less repetition. Comment aborted. Your comment has too few characters per line (currently 18.5). Your comment has too few characters per line.

Now it says: Your commen7 has too few characters per line (currently 33.7). However, I didn't change the number of lines.

# Important Stuff: Please try to keep posts on topic. # Try to reply to other people's comments instead of starting new threads. # Read other people's messages before posting your own to avoid simply duplicating what has already been said. # Use a clear subject that describes what your message is about. # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjust