Wow, you must've been the most feared one on your high school debate team. Never in the annals of history has one so fomiddable in the artform of debate has one existed as great and unbeatable as justins.
In a pig's eye. You're not even a very good troll.
Sorry, but this isn't the playground, and apache can't just take their ball and go home. Unless SCO has violated the apache software license, the apache foundation cannot just suddenly remove the rights of SCO under that license because it "feels like it."
SCO has violated the GPL. Companies that distribute their software under the GPL have a right to withdraw the licensing of SCO because the GPL gives them that right due to the violation.
No such clause exists in the apache software license that if you violate the GPL they can pull your rights.
Actually, it's VITALLY important. It proves that the different companies that support postgresql are more than just houses of funky consultants with little or no experience. These support companies actively write both free and commercial add ons to the database, and therefore are guaranteed to have in house talent to meet your needs should you have a really difficult problem to work out.
Here are a few more companies that provide both products and support for postgresql.
How many companies are providing support for MySQL besides MySQL? How much choice do you have, and how good is it?
http://www.linuxlabs.com/welcome.html -> Clustered Postgresql solutions and postgresql support contracts http://www.refractions.net/ -> PostGIS indexing and postgresql support contracts http://www.dbexperts.net/ -> clustering and postgresql support contracts www.nusphere.com -> IDE for PHP/Postgresql, Native windows port of Postgresql, support for their native windows port.
Note that all of these, including those in my grandparent post, provide both full postgresql support in ADDITION to those products they provide and the support for said products.
Look, you were WRONG. Absolutely, and unequivocably wrong. Postgresql has real companies providing real support. It runs real databases where data integrity and 24/7 operation are critical to the business, and it does so quite well, and one of the reasons it does so is that it is very well supported, both by the community and by commercial companies with a stake in seeing it succeed.
MySQL is a single source product. One company does virtually all the development, and all the support. And if they aren't doing what you want, you're options are significantly more limited than they are with Postgresql.
Those are facts. Your original post was a lie of ignorance. Your further defending it just makes you look so much more desperate.
Yep, I remember that too. What happened is that some whiz kid 'leet hacker at MS used the upper 8 bits of the 32 bit address space on the 68000 to store miscellaneous data. when the 68020/030/040 came out with a full 32 bit address space, AmigaBasic crashed because now those bits meant something.
Keep in mind, Commodore made it very clear from the beginning that using those upper bits was a very bad thing and to be avoided. But sometimes people are more interested in using strange and arcane methods to impress their friends than in writing good code.
QUOTE: I'm not aware of any database that 100% follow the SQL specs. UNQUOTE:
But, don't you think a database with SQL in it's name might make some small effort to follow the specification? Nah, I guess not.
But the real issue is that data coherency is the job of the database, not the code that sits on top. While there may be dozens of pieces of code that touch a database, there is only one small point of entry, the database. relying on code to make sure your data is coherent is suicide.
Sorry, but the SQL spec specifically says those are bugs, not features. You shouldn't have to work around bugs in a SQL database in order to have coherent data. If you don't understand that point, you probably shouldn't be programming database applications that hold any kind of critical information. Imagine a bug like that popping up in the middle of a bank year, and only being caught several months later. Disaster.
www.pgsql.com www.commandprompt.com www.redhat.c om
Postgresql has REAL commercial support, and it isn't being sold by one company trying to extort money out of you for using their product commercially. It's supported by several different companies, and if you don't find one fits your needs, you can pick another.
unfortunately, MySQL still has many other issues that innodb tables cannot fix.
It allows you to insert a data of 0000-00-00. It allows you to overflow an int field with no error. There are others. Google search for "mysql gotchas"
create table test (id int4); insert into test values (123456789012345); select * from test;
id | | 2147483647 | 1 row in set (0.01 sec)
Huh. I could have sworn I tried to insert a number that was too big. But somehow, instead of throwing an error, MySQL just put in the biggest number it could. Would be real nice to see in an accounting system, huh?
1: The OO stuff as regards table inheritence is broken, and no one's in a hurry to fix it. 2: It's easy for me to install, for some people, not so much. 3: FirebirdSQL is just as free as PostgreSQL, using their own version of the Mozilla Public License.
The main things that PostgreSQL is that FirebirdSQL is not is heavily tested in enterprise environments. Remember, every time you go to slashdot.org, the database serving up that site is MySQL, but the database serving up the IP for that.org site is PostgreSQL.
However, I totally agree there's a negative probability that anyone will ever use the name Postgresql for any other project.
Ohhh. and I need a dump truck that's fast and small, but can carry 28 metric tonnes of stone at the same time. And it needs a built in hot tub. And a satellite dish.
Comon, every piece of software is a compromise. If you need a lot of features, then it isn't gonna be small. If you need it small and fast it's gonna be missing some features.
No matter what you were trying to do, what you did was to characterize the postings Cajal as a flame (i.e. MySQL SUCKS!)
In fact he carefully pointed out the areas where MySQL is strong, as well as the areas it is weak, and why he would or would not recommend it.
Each time he did this, you kept taking it personally, and responding with emotion laden, logically fallacious arguments that proved no point other than the fact that you take these things far too personally.
Keep in mind, in this same thread, I also pointed out that MySQL has jobs for which it is particularly well suited (content management, report generation, etc...)
Cajal was being characterized as attacking MySQL in your post, which he most certainly did not do.
The point of my post, which apparently went straight over your head, was that the argument had gone far different than you had portrayed it, and that in fact while Cajal was being quite civilized and presenting his points in a non-emotional and non-insulting manner, you, sir (or madam) insisted on treating it like a flame fest.
Your response showing how many place MySQL works is an emotional appeal used to try and win a logical argument, and it just doesn't work.
The fact that it can be used for contact management, shopping carts, and content management in no way obviates the obvious flaws it does have, it simply means that for those tasks, those flaws are not a show stopper, or maybe even work for it, since they simplify the code path and allow it to run faster.
The fact is, Cajal brought up cogent points, and your constant response to him was "Stop flaming me, MySQL does NOT suck, nuh uh, I'm not gonna listen" and so on. I use Postgresql and MySQL for different projects, and know the weaknesses of both. There are some problems I would recommend one or the other to solve, and many that they overlap on. Each has its strenghs and weaknesses, and to just run around saying "MySQL is the best because it just is" accomplishes nothing. If you want to have a solid logical argument, feel free to start one. So far, you've done little but to insult those who have a differing view point by claiming they are attacking you and your favorite database in the whole world.
Don't take this stuff so personally. In a hundred years, we'll both be dead ya know.
Note that there has been a lot of work in the last year to get Postgresql running faster on Solaris, including several fixes to Solaris itself, such as it's (Solaris') very very (very very???) slow qsort with lots of equal keys being replaced by BSD's qsort.
You might want to try it again, and report back to the pgsql-performance list to see if they can get you some help.
ngunton: MySQL's many bugs aren't a problem. It works fine. I've never seen data loss, so it must not happen. Cajal: well, actually, there are problems here they are: (list of problems follows) ngunton: Nu uh! You're saying MySQL is evil, you're mean. MySQL works. It works it works it works it works, and I won't believe you. Cajal: But, here's the list (repeat list) ngunton: Nuh uh! You're saying MySQL is evil, you're mean. MySQL works. It works it works it works it works, and I won't believe you
I would say that there are zealots on BOTH sides, and painting all the supporters of either product as zealots is insulting. so, this thread started with an insult, the z word, and some people took it a little personally, which is understandable.
Your last paragraph, where you say:
As for the 8k row limits, so, in this regard, MySQL was in fact *better* than the big databases such as MSSQL and Oracle? So why, instead of complementing MySQL for this accomplishment do we slam it as a toy database?
shows the MySQL crowd's tendency to major in minors and minor in majors. The most important part of a transactional, SQL spec compliant database is that you can wrap all your work up in transactions, and be sure that "all or nothing" goes through, not partial updates that leave your data in an inconsistent state.
I.e. trumpeting >8k row size as an advantage while still not having transactions (i.e. the past versions of MySQL, pre-innodb) is like selling a car based on the wide choice of colors it is available it. It's not an overly important point for a database, whose primary responsibility is to reliably store related data in a method that ensures the integrity of your data.
Good exchange, hope to see you around in the future...
Cool, I get your point on most of what you say, but, this:
It would be a reasonable complaint if MySQL didn't have an ANSI-compliant mode, which it does.
doesn't fix all the problems. It fixes quite a few, but the ones that are left are still pretty nasty, imnsho.
Further, about Postgresql, you said:
2. The documentation is crap. Actually it's worse than crap, but going into that in detail would be off-topic. (Whereas the MySQL documentation is mostly very, very good.)
I call shenanigans. While the Postgresql docs are not aimed at the beginner, as someone who already understands database theory, I found them quite good. I didn't need someone to point out what a foreign key was or what it could do, only how Postgresql implemented it. While the MySQL docs are great for beginners, they are actually pretty damned cumbersome for people with experience. Also, the Postgresql docs have had a lot of input in the last year or so, so you might want to look at them again.
I'll just add to the other comments and say that Postgresql is a moving target, under active development by a very talented team, so while MySQL tries to play catchup, Postgresql moves on ahead as well.
The things coming in the next year or so are: Point in Time Recovery Sub transactions Very low I/O contention vacuuming. Win32 native port Multi-master / multi-slave async replication
In the last year, postgresql has added other key features as well, such as industrial strength synchronous replication (.org uses postgresql with this solution), GiST indexes, ssl/ssh connections, many new procedural languages (R, PHP, python, java), and most importantly, performance improvements.
Slashdot Mirror
Wow, you must've been the most feared one on your high school debate team. Never in the annals of history has one so fomiddable in the artform of debate has one existed as great and unbeatable as justins.
In a pig's eye. You're not even a very good troll.
That makes perfect sense to me. I wonder why they haven't done it yet.
Sorry, but this isn't the playground, and apache can't just take their ball and go home. Unless SCO has violated the apache software license, the apache foundation cannot just suddenly remove the rights of SCO under that license because it "feels like it."
SCO has violated the GPL. Companies that distribute their software under the GPL have a right to withdraw the licensing of SCO because the GPL gives them that right due to the violation.
No such clause exists in the apache software license that if you violate the GPL they can pull your rights.
Actually, it's VITALLY important. It proves that the different companies that support postgresql are more than just houses of funky consultants with little or no experience. These support companies actively write both free and commercial add ons to the database, and therefore are guaranteed to have in house talent to meet your needs should you have a really difficult problem to work out.
Here are a few more companies that provide both products and support for postgresql.
How many companies are providing support for MySQL besides MySQL? How much choice do you have, and how good is it?
http://www.linuxlabs.com/welcome.html -> Clustered Postgresql solutions and postgresql support contracts
http://www.refractions.net/ -> PostGIS indexing and postgresql support contracts
http://www.dbexperts.net/ -> clustering and postgresql support contracts
www.nusphere.com -> IDE for PHP/Postgresql, Native windows port of Postgresql, support for their native windows port.
Note that all of these, including those in my grandparent post, provide both full postgresql support in ADDITION to those products they provide and the support for said products.
Look, you were WRONG. Absolutely, and unequivocably wrong. Postgresql has real companies providing real support. It runs real databases where data integrity and 24/7 operation are critical to the business, and it does so quite well, and one of the reasons it does so is that it is very well supported, both by the community and by commercial companies with a stake in seeing it succeed.
MySQL is a single source product. One company does virtually all the development, and all the support. And if they aren't doing what you want, you're options are significantly more limited than they are with Postgresql.
Those are facts. Your original post was a lie of ignorance. Your further defending it just makes you look so much more desperate.
Yeah, they're so unimportant that they provide the replication code that afilias uses to run .org and .info on.
and plperl, plphp, and a half a dozen other useful parts of postgresql.
Yep, never heard of them before.
Just because your outlook is limited, don't expect everyone else's to be.
Yep, I remember that too. What happened is that some whiz kid 'leet hacker at MS used the upper 8 bits of the 32 bit address space on the 68000 to store miscellaneous data. when the 68020/030/040 came out with a full 32 bit address space, AmigaBasic crashed because now those bits meant something.
Keep in mind, Commodore made it very clear from the beginning that using those upper bits was a very bad thing and to be avoided. But sometimes people are more interested in using strange and arcane methods to impress their friends than in writing good code.
QUOTE:
I'm not aware of any database that 100% follow the SQL specs.
UNQUOTE:
But, don't you think a database with SQL in it's name might make some small effort to follow the specification? Nah, I guess not.
But the real issue is that data coherency is the job of the database, not the code that sits on top. While there may be dozens of pieces of code that touch a database, there is only one small point of entry, the database. relying on code to make sure your data is coherent is suicide.
I guess Irony can be pretty ironic sometimes...
(A quote from the old Police Squad show...)
I should clarify, that the statement:
:-)
The only non-transactable DDL / DML command is create / drop database...
was in reference to Postgresql.
Sorry, but the SQL spec specifically says those are bugs, not features. You shouldn't have to work around bugs in a SQL database in order to have coherent data. If you don't understand that point, you probably shouldn't be programming database applications that hold any kind of critical information. Imagine a bug like that popping up in the middle of a bank year, and only being caught several months later. Disaster.
So, name me a complex load or transaction set that Firebird can handle that Postgresql can't?
Or are distributed transactions the defining keypoint of a "commercial grade" dbms?
www.pgsql.comc om
www.commandprompt.com
www.redhat.
Postgresql has REAL commercial support, and it isn't being sold by one company trying to extort money out of you for using their product commercially.
It's supported by several different companies, and if you don't find one fits your needs, you can pick another.
If Firebird is the only free commercial quality database, why isn't it running the .org and .info domains?
There is a free database running those domains, but it ain't MySQL or Firebird.
unfortunately, MySQL still has many other issues that innodb tables cannot fix.
It allows you to insert a data of 0000-00-00.
It allows you to overflow an int field with no error.
There are others. Google search for "mysql gotchas"
The same thing as Oracle 9i, it errors out because DDL isn't transactable in very many databases.
:-)
The only non-transactable DDL / DML command is create / drop database...
Here's how:
create table test (id int4);
insert into test values (123456789012345);
select * from test;
id |
| 2147483647 |
1 row in set (0.01 sec)
Huh. I could have sworn I tried to insert a number that was too big. But somehow, instead of throwing an error, MySQL just put in the biggest number it could. Would be real nice to see in an accounting system, huh?
Check here for more problems with MySQL:
http://sql-info.de/mysql/gotchas.html
I too love postgresql, but let's be honest:
.org site is PostgreSQL.
1: The OO stuff as regards table inheritence is broken, and no one's in a hurry to fix it.
2: It's easy for me to install, for some people, not so much.
3: FirebirdSQL is just as free as PostgreSQL, using their own version of the Mozilla Public License.
The main things that PostgreSQL is that FirebirdSQL is not is heavily tested in enterprise environments. Remember, every time you go to slashdot.org, the database serving up that site is MySQL, but the database serving up the IP for that
However, I totally agree there's a negative probability that anyone will ever use the name Postgresql for any other project.
Ohhh. and I need a dump truck that's fast and small, but can carry 28 metric tonnes of stone at the same time. And it needs a built in hot tub. And a satellite dish.
Comon, every piece of software is a compromise. If you need a lot of features, then it isn't gonna be small. If you need it small and fast it's gonna be missing some features.
Fast, featureful, small. Pick two.
No matter what you were trying to do, what you did was to characterize the postings Cajal as a flame (i.e. MySQL SUCKS!)
In fact he carefully pointed out the areas where MySQL is strong, as well as the areas it is weak, and why he would or would not recommend it.
Each time he did this, you kept taking it personally, and responding with emotion laden, logically fallacious arguments that proved no point other than the fact that you take these things far too personally.
Keep in mind, in this same thread, I also pointed out that MySQL has jobs for which it is particularly well suited (content management, report generation, etc...)
Cajal was being characterized as attacking MySQL in your post, which he most certainly did not do.
The point of my post, which apparently went straight over your head, was that the argument had gone far different than you had portrayed it, and that in fact while Cajal was being quite civilized and presenting his points in a non-emotional and non-insulting manner, you, sir (or madam) insisted on treating it like a flame fest.
Your response showing how many place MySQL works is an emotional appeal used to try and win a logical argument, and it just doesn't work.
The fact that it can be used for contact management, shopping carts, and content management in no way obviates the obvious flaws it does have, it simply means that for those tasks, those flaws are not a show stopper, or maybe even work for it, since they simplify the code path and allow it to run faster.
The fact is, Cajal brought up cogent points, and your constant response to him was "Stop flaming me, MySQL does NOT suck, nuh uh, I'm not gonna listen" and so on. I use Postgresql and MySQL for different projects, and know the weaknesses of both. There are some problems I would recommend one or the other to solve, and many that they overlap on. Each has its strenghs and weaknesses, and to just run around saying "MySQL is the best because it just is" accomplishes nothing. If you want to have a solid logical argument, feel free to start one. So far, you've done little but to insult those who have a differing view point by claiming they are attacking you and your favorite database in the whole world.
Don't take this stuff so personally. In a hundred years, we'll both be dead ya know.
Note that there has been a lot of work in the last year to get Postgresql running faster on Solaris, including several fixes to Solaris itself, such as it's (Solaris') very very (very very???) slow qsort with lots of equal keys being replaced by BSD's qsort.
You might want to try it again, and report back to the pgsql-performance list to see if they can get you some help.
No, here's a more accurate one:
ngunton: MySQL's many bugs aren't a problem. It works fine. I've never seen data loss, so it must not happen.
Cajal: well, actually, there are problems here they are: (list of problems follows)
ngunton: Nu uh! You're saying MySQL is evil, you're mean. MySQL works. It works it works it works it works, and I won't believe you.
Cajal: But, here's the list (repeat list)
ngunton: Nuh uh! You're saying MySQL is evil, you're mean. MySQL works. It works it works it works it works, and I won't believe you
repeat until dizzy.
You are in such dire need of a sarcasm infusion.
I would say that there are zealots on BOTH sides, and painting all the supporters of either product as zealots is insulting. so, this thread started with an insult, the z word, and some people took it a little personally, which is understandable.
Your last paragraph, where you say:
As for the 8k row limits, so, in this regard, MySQL was in fact *better* than the big databases such as MSSQL and Oracle? So why, instead of complementing MySQL for this accomplishment do we slam it as a toy database?
shows the MySQL crowd's tendency to major in minors and minor in majors. The most important part of a transactional, SQL spec compliant database is that you can wrap all your work up in transactions, and be sure that "all or nothing" goes through, not partial updates that leave your data in an inconsistent state.
I.e. trumpeting >8k row size as an advantage while still not having transactions (i.e. the past versions of MySQL, pre-innodb) is like selling a car based on the wide choice of colors it is available it. It's not an overly important point for a database, whose primary responsibility is to reliably store related data in a method that ensures the integrity of your data.
Good exchange, hope to see you around in the future...
Cool, I get your point on most of what you say, but, this:
It would be a reasonable complaint if MySQL didn't have an ANSI-compliant mode, which it does.
doesn't fix all the problems. It fixes quite a few, but the ones that are left are still pretty nasty, imnsho.
Further, about Postgresql, you said:
2. The documentation is crap. Actually it's worse than crap, but going into that in detail would be off-topic. (Whereas the MySQL documentation is mostly very, very good.)
I call shenanigans. While the Postgresql docs are not aimed at the beginner, as someone who already understands database theory, I found them quite good. I didn't need someone to point out what a foreign key was or what it could do, only how Postgresql implemented it. While the MySQL docs are great for beginners, they are actually pretty damned cumbersome for people with experience. Also, the Postgresql docs have had a lot of input in the last year or so, so you might want to look at them again.
Congrats on being curious enough to look.
I'll just add to the other comments and say that Postgresql is a moving target, under active development by a very talented team, so while MySQL tries to play catchup, Postgresql moves on ahead as well.
The things coming in the next year or so are:
Point in Time Recovery
Sub transactions
Very low I/O contention vacuuming.
Win32 native port
Multi-master / multi-slave async replication
In the last year, postgresql has added other key features as well, such as industrial strength synchronous replication (.org uses postgresql with this solution), GiST indexes, ssl/ssh connections, many new procedural languages (R, PHP, python, java), and most importantly, performance improvements.