Slashdot Mirror
PostgreSQL Slammed by PHP Creator
leifbk writes "'The Web is broken and it's all your fault' says Rasmus Lerdorf, the creator of PHP. He talks about not trusting user input, and the brokenness of IE, which is all fine. Then he makes a statement about MySQL vs PostgreSQL: 'If you can fit your problem into what MySQL can handle it's very fast,' Lerdorf said. 'You can gain quite a bit of performance.' For the items that MySQL doesn't handle as well as PostgreSQL, Lerdorf noted that some features can be emulated in PHP itself, and you still end up with a net performance boost. Naturally, the PostgreSQL community is rather unimpressed. One of the more amusing replies: 'I wasn't able to find anything the article worth discussing. If you give up A, C, I, and D, of course you get better performance- just like you can get better performance from a wheel-less Yugo if you slide it down a luge track.'"
It's very fast and I haven't been killed yet.
Honestly, just avoid this discussion by using flat files.
"If A equals success, then the formua is A=X+Y+Z. X is work. Y is play. Z is keep your mouth shut" - A Einstein.
If I 'emulate' enough features in the code, I can do away with both packages AND still get a performance boost. Probably. However, the whole point of having a seperate package do it is so I dont have to work more than needed.
"Rasmus Lerdorf, the creator of PHP ... said the current state of the Internet includes a litany of broken items, but with a little help from PHP there may well be some hope for the Web yet."
...
I wonder if he has ever consider using Perl
Hulk SMASH Celiac Disease
The creator of PHP thinks that PHP is #1 and all others are #2 or lower? Shocking.
They say to a man with a hammer, everything looks like a nail. I'm sure it was even worse for the guy who invented the hammer.
he's quite full of himself, isn't he?
the web is "broken" independant of the language used. bad/inexperienced developers are causing the problems, no matter what language is used. in order to not shoot yourself in the foot, you have to know that you're holding a gun and that pointing it at your foot and pulling the trigger are bad things to do.
and mysql and postgresql are different. they both have strengths and weaknesses. you can hammer in a screw faster than using a screwdriver, but thats not the friggin point of it.
Considering that this is coming from the author of one of the worst hack-jobs of a language since Visual Basic, I'm going to have to give his opinions a pass. Pragmatism is great, but even Perl has principles.
I got my Linux laptop at System76.
Why would we listen to the creator of a badly performing broken scripting language about a reliable performance oriented DB?
Not the whole world is interested in rendering HTML tables with blathering text.
The cesspool just got a check and balance.
This guy is an idiot. PHP is a nice product though, if anyone can get past its inconsistent function naming schemes.
He also states:
He *just* learned that? Oh my, that's scary.
MySQL is made for speed compromising to act like a database where it does not break its own convenience. PostgreSQL is a database which will compromise for speed, if it does not break the database.
From someone who obviously is suprised that to secure something you need to make a safe-house and then be strict about what gets in, it seems that he missed the point on the MySQL/PostgreSQL thing.
Maybe by the next conference he'll grow up and state the new revelation "You have to use a database like PostgreSQL and use a warehouse schema to allow faster reporting."
====
Nor was this a "slam". PostgreSQL is not made for specifically web use. If anything, Lerdorf merely publicly demonstrated his own immaturity.
Have you read my journal today?
You are basing this on a rather incomplete account of my actual talk. I went through a series of optimizations of a sample Web application, and one of many steps was to try MySQL instead of PostgreSQL for that particular application. By profiling it with Callgrind it was obvious that in this particular case MySQL was significantly faster. I don't think this is news to anybody that MySQL is quicker at connecting and issueing simple queries, and I am not sure why me showing some Callgrind profiles and stating that MySQL is particular good at these things is frontpage slashdot material. Slow day?
And the "The Web is broken and it is all your fault" thing was just a bit of humour to wake people up for this 9am talk, but I guess it makes for good headlines.
While people might not agree with me that PHP is horribly broken, I think we can all agree that if we were to choose between Apache, PHP and Postgresql as to what made the web more broken, I think almost everyone would pick PHP. The reason can be summed up as bad design decisions in PHP (slashes, inconsistent naming, header fun, etc.).
I don't blast someone if they choose the smaller learning curve with PHP + Mysql, but they're certainly not the superior solution compared to for example Perl/Python + Postgresql/Oracle.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
I've used MySQL on several projects. At first because we didn't know any better, later because it was the thing we knew best, or because the project was already using it when I joined it. Inertia. We're using a 5.0.x now, on a setup where we replicate to six slaves, it's not small.
I knew that MySQL could do stupid things now and then, but at least it was our stupid thing. We have some experience with it, by now.
Recently though, some colleagues on another project had an issue with major data loss - an input script had put data into the database that wasn't really compatible with the data model.
Turns out that in a table with an auto-increment primary key named 'id', some of those ids occurred over 200 times. A primary key.
I don't care if there's options or ways to have it check that, even without "emulating it in PHP" (shudder) - anything that is even considering putting "SQL" in its name has to complain loudly when someone tries to insert such crap, and then abort. Not just silently accept it.
That's the eternal problem with MySQL - everywhere, the default action on wrong input is to silently continue, perhaps trying to read the mind of the programmer and turn the nonsensical value into some equally nonsensical default. Put a string into an int field? Let me guess what you meant... etc.
I've had it, I don't want MySQL anymore.
I've been writing Perl for 6 years now and I've yet to find a more versatile language. I just started working in PHP, and it's Perl-like enough that learning it has been easy. But some things are just not done elegantly, and one has to wonder why that is, given that PHP is in fact pretty good as languages go.
GetOuttaMySpace - The Anti-Social Network
The headline implies that Rasmus blames PostgreSQL for breaking the web which is not the case. The focus of his ire is web application programmers for putting too much trust in user input. I don't think anyone can truthfully argue with that.
His comment regarding PostgreSQL was:
"If you can fit your problem into what MySQL can handle it's very fast, you can gain quite a bit of performance."
As someone who uses both MySQL and PostgreSQL in production environments, I couldn't agree more. The key qualifier is "If you can fit your problem into what MySQL can handle". In order to argue that this statement is wrong you would have to argue that PostgreSQL is faster than MySQL in situations that are ideal for MySQL.
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-U
I got sick of the syntax dialects of every SQL engine, so I started writing my applications using Hibernate and haven't looked back.
I learned HQL (Hibernate Query Language) and just use whatever database is handy at the time.
I usually start with MySQL 5, and then if I need more muscle (Read: the boss wants to spend money), I can switch the entire application to Oracle in about two hours.
You want ACID...? Use J2EE transactions and Hibernate, and never worry about which database you use again.
"'The Web is broken and it's all your fault' says Rasmus Lerdorf, the creator of PHP."
Translation:
"Hello, Kettle? Yes, this is Pot. What colour are you..?"
Really, if Lerdorf wants to know who broke the web, he just needs to look in a mirror.
PHP/FI was the second version, and it wasn't written in Perl. Neither was the first version. The first version of PHP replaced some Perl code which may be where this myth comes from.
Recently, I've been using Drupal (PHP CMS system) with a MySQL backend and I am STUNNED, STUNNED I SAY by how productive the combination is compared with, say, ASP.NET and SQL Server. It's a messy, awkward, ambiguous and utterly unscalable language with a cluttered global namespace stuffed full of magic variables and near-identical functions -- combined with a 'database' that simply does not do what a proper database does. And I love it!
...I want PHP and MySQL!
I don't understand this compulsion to prove that PHP and MySQL are good. They're not good. They're sh*t. They're extremely old fashioned and underpowered solutions to problems that are already solved far more effectively in the MS world AND in the OSS world AND even in the proprietary Unix world. Every time I poke around in the Drupal source I have a little smugness session as I think how much clearer and more efficient and more cleanly extendible it could be in C#, or even Java. Then I go right back to using it -- not because it's good, but because for the size of task I'm using it for, it's productive.
Sure, SQL Server is better and so is PostgreSQL, and sure, the antics of LAMP people to prove that PHP and MySQL (and CVS, for that matter) are real grown up systems are laughable. But so what? I'm not trying to be scalable or extensible or secure beyond very narrow parameters that I already know fall within the limited scope of PHP and MySQL. I don't want to use the best tools; I'm familiar with the best tools and the scale of operation they best suit. When I want the following methodology:
GET
gunzip
tar -xvf
vim vim vim
exit
(end of long meandering rant)
Whence? Hence. Whither? Thither.
APC is broken in so many ways it is unbelievable.
eAccelerator however performs a thousand times better and actually works.
Ever new major php build makes noticeable efforts to break eAccelerator while making concessions to APC.
It is very frustrating. APC just plain sucks. eAcclerator rocks.
Kindness is not to be found in anything but that it adds to its beauty...
Yep: http://thedailywtf.com/forums/thread/60879.aspx
Are you saying a Slashdot editor didn't bother to fully read the article and just made up a sensational and misleading headline in order to troll for mouse-clicks?
I don't believe you.
I've been writing Perl for 6 years ....
Anyone else misread this as "I've been WAITING for Perl 6 for years"?
FWIW, the commercial database UNIFY used to be pretty much the same thing back in the mid-80s. They had a wicked-fast ISAM database, and then they wrapped that all up in an SQL wrapper. They were a little more concientious, though, so you had guaranteed atomic transactions and rollback capability and more complete SQL support (e.g., nested/correlated subqueries), so it was truly relational (as the term is generally used). Horrible syntax-based optimizer, though (actually, I'm not even convinced it was an optimizer, it was probably just the way their SQL parser interpreted the query).
Just junk food for thought...
Here is a good summary of some of my complaints. But wait, there is more:
As a programming language, php is extremelly poor. Off the top of my head:
and then there is the issue of all the weird behaviours it has
The language itself seems to promote what Rasmus calls "broken" code. Magic quotes are just an open invitation for SQL Injection, and XSS vulnerabilities.
For fck sake, the php tutorial teaches how to write cross site script vulnerable code which is what Rasmus is complaining about. WTF?????
P.S. Forgive my grammar, english is my second language
"just like you can get better performance from a wheel-less Yugo if you slide it down a luge track."
I am sick and tired of seeing these sweeping, baseless statements on Slashdot. The body of a Yugo is much too wide to sit flat on the ice of a luge track.
Editors, please start doing some fact checking before posting this stuff.
#DeleteChrome
The feature you are talking about is vital to the proper operation of a real database. The "transactional reasons" you refer too are the difference between a "real" database and a toy like "mysql" (which is neither yours nor very good SQL) Imagine two operations concurrently operating on a database, one in the process of modifying the data, the other simply reading it. The first process starts a transaction and makes a lot of changes, then commits the changes. The second query just wants to execute a quick query. The second query gets its data and is done. When the first operation finishes, its changes become available. No one had to wait for anything. In MySQL, the second query would have to wait. As we see in so many MySQL web sites, as the waiters pile up, sooner or later you run out of MySQL connections and start to get error messages. IMHO, one of the reasons why the web is broken is that it is so easy to create content that no one takes the time to learn the basic computer science involved. When things break or perform poorly, they blame everyone but themselves. There is REAL science in computers, if if you ignore it, you'll never do anything worth while.
"PostgreSQL sucks." - From the guy who brought us magic quotes
Exactly. But it makes a much more interesting /. story to take an imcomplete account of a talk and further mangle it.
I've been writing Perl for 6 years now and I've yet to find a more versatile language.
I've been writing in Perl for 13 years and detest supporting the crap code written by people who think it's applicable to every problem domain.
SQLite.
Why is it that many people who claim to support standards have such atrocious spelling and grammar?
Isn't this flamewar old enough for people to start ignoring it? Holy cow: the mySQL vs. postgres argument has been hashed and rehashed so long... isn't about time we realized that neither is a clear all-encompassing winner over the other?
They do. And unfortunately I have direct experience with these people... and for the record, I *mostly* hate it.
Where I work, some of the architects and designers have decided to store more than a little XML in Oracle tables. In some cases this is not an entirely onerus decision (i.e. can make sense). e.g. if you are storing standardized configuration information in XML that will be queried as a string from the table and can be used by/passed to different consumer services/applications as an atomic unit (and which is not used in whole or in part as an sql 'where' predicate), then it can work.
However any time you may need to query information contained in the XML string, it seems to me to be kind of retarded to store it in a relational table. e.g. I have seen cases where IDs or service types etc. are stored in a large XML string in a field in a record, and eventually someone wants to retrieve a record based on that ID which is in the XML. This means parsing the field storing the XML in your query, killing any chances on performance since you are likely going to need a 'like' clause with wild cards at the front and back of the search term (even if the RDBMS has a built in XML search tool, the field still needs to be parsed). Unfortunately, people buy in to XML so much that some think that it is still OK to store XML in database tables... even in these cases.
I personally think it is generally a bad idea to store XML in a relational database as eventually the 2nd situation will come about (that is what experience tells me). You will then find that the practice totally negates the benefit of a relational database and sql (language) to easily and quickly retrieve relational data. I have seen this bite people many times. Ahhh... to use a technology, even a useful one, just because it is hip... but that is just my experience.
-- I ignore anonymous replies to my comments and postings.
PHP through 4.1 was an AWESOME prototyping language... what it was designed for. Back then, you could POST or GET a form, and the variables were automatically filled in. This was a huge security whole, and therefore plugged, which has made it less useful in some ways, but more production friendly in others.
However, my old partner when to a PHP conference, and was STUNNED that the recommended course of action was:
1. Use PHP to prototype
2. Move all business login into C or C++
3. Call the business logic from PHP wrapping the C/C++ calls
While that may be more "correct," that would have massively increased development time.
Our current cycle is like this:
1. Prototype in PHP and PostgreSQL in a test database, treating it like MySQL or Access (a retarded database)
2. Move all validation code into the database with pl/pgSQL, using triggers, etc
3. Performance tune by creating (using triggers) optimized tables for the live site.
4. Deploy
This gets us a lightening fast, reliable system. Unfortunately, for legacy reasons, we have so much PHP code that we've written that migrating to something else (including PHP 5) is hard to justify until we have the budget to get the extra staff just to migrate the system.
It's more work on the DB side, but it's well worth it.
One of the performance tunes we've considered: pl/php, which last time we evaluated it, wasn't quite ready for prime time. Our idea: after tuning your database, move all your database access into the database.
Essentially, for each "page type" on a dynamic site, create a php function that gathers ALL the data you need and puts it into an array. Then, call the Database PHP function getPageType("values to be passed"). The server side PHP function will do all the queries you need, serialize the array, and return it as a TEXT value. Your web page deserializes and displays.
The reason for this is that you have several delays and resource hogs:
1. unoptimized queries: before you move things to stored procedures, test your SQL with explain. Add indexes as needed. If you look up on two or three values, create an index on those values... basic stuff, but will get you massive speed-ups.
2. database connections, to keep this down, put everything on the server into one database and use schemas for access, now you can use persistent connections with a "web" user that connects in persistently and switches as needed (or make your getPage functions accessible to the web user... SECURITY definer, grant execute to the web user).
3. back-and-forth connections: the best way to kill performance, have a PHP script that calls the database, gets some data, calculates on it, and queries again... the fewer queries to the database a page, the better, less overhead. If you need to do back-and-forth activity, write a stored procedure, then there is a single database call. PostgreSQL lets you write stored procedures in SQL, so there is no excuse not to do it.
If you are doing a project of any magnitude, (i.e. 2-3 programmers on it), then one of you should learn to play DBA and optimize the database. If you do that, PostgreSQL is a fast moving beast.
Most performance competitions are MySQL users testing PostgreSQL. However, if you use PostgreSQL like MySQL, it's dog slow. MySQL is a "retarded" database with almost no overhead, so querying the database 15-20 times on a page is harmless. PostgreSQL requires database administration. Once you set up your database right, and tune the server settings (increase buffers, allocate more sort memory, etc.) it screams, but you have to treat it like a real DB.
If you are just throwing your thoughts up on the web, it's not worth it, but if you are doing a real "small" project, where the license for Oracle, DB2, or even MS SQL Server would be extravagant, PostgreSQL is a great option. (The problem with the real databases isn't just the price tag, it's that they are more powerful IF configured right, so you end up needing a 6-figure DBA, instead of a book on database design and about 12 hours to get used to writing triggers).
Alex
Excuse me Rasmus, but aren't you teaching how to write XSS vulnerable code in your php tutorial?
And yet none of that explains why it is necessary for the original record to persist indefinitely.
It isn't "indefinitely," it is until vacuum is run, and yes, queries run while vaccum is operating.
Every database that has "multi-versioning" needs some sort of "purge" operation. It is all how and when it is executed.
which is neither yours nor very good SQL
s istent-read.html
Open-source GPL + optional commercial licensing not good enough for you?
real database
But maybe we don't need a "real" database. Maybe we need an easy-to-use replacement for flat files with some database features. Not everyone is running a bank, or handling a billion emails a day, or tracking inventory for Wal-Mart. Lots of users just want something that can handle their small little application.
IMHO, one of the reasons why the web is broken is that it is so easy to create content that no one takes the time to learn the basic computer science involved
Spoken like a true CS major. CS is a valuable, valuable field - I have nothing but the highest respect for it (which is why I'm getting an ECE degree + CS minor). But the web is not 'broken' - it is the single most valuable informational resource that we have ever created. And the web is useful precisely because you don't have to understand CS to create content. Do you think that there would be 1/1000th of the content on the web if you had to understand CS to contribute to it? No. What we would end up with would be a web that consists entirely of pages created by pencilnecks like yourself and by corporations with big budgets. There would be no Slashdot. There would be no Wikipedia.
In MySQL, the second query would have to wait.
Perhaps you should stop using MyISAM and start using InnoDB:
http://dev.mysql.com/doc/refman/5.0/en/innodb-con
Basically, they needed to aggregate data from about 56 million rows in table, and required a self-join as well. I got the consulting contract because this was taking at least six days to complete.
Inputting the 56 million records took about a hour; this included creating three indices.
So far so good. At that point, to make in run faster, I wanted to pre-calculate and deformalize the data the self-join would give. I'd already included columns for this denormalized data in the table, so it was pretty much
A simple correlated subquery self-join in a update. Low and behold, MySQL doesn't allow this,. at all:
Ok, so instead of a subquery we can do a join, but that means we have to throw away the max() operation. Without the max predicate we're doing 1-to-Many joins on b where there is more than one row matching our criteria, and so we're potentially doing multiple updates (all but one of which gets "thrown away") to a row.
Ok, so far so good.
First time around, I included the demoralized column in an index, and of course the update changed the column values. If I dropped and re-created the index, MySQL took about four hours to re-index (four times the time it took to make the index when it BCP'd it in). But if I repaired the index, rather than dropping it, well, it never actually completed, becasue after two days I killed it. What the hell?
Finally, to display the data, I needed to do some date manipulation, a lot of it repeated. In pg, I'd have written the code once, in a user defined function. In MySQL, that requires compiling a shared library, so instead I repeated these rather long calculations in a select. Tedious and error prone. (In MySQL's favor, the built-in date functions are a lot cleaner than T-SQL's.)
Eventually I got a six-day or longer process down to three hours, but it wasn't pretty.
So long story short: a business goes with MySQL because it's "fast". At a certain point, it ceases to scale, and you have to perform "heroic measures", denormalizing and pre-calculating. The index repair is a mess. You can't easily encapsulate code in functions or, prior to 5.0, views. It's no longer fast, and your mission critical business requires calling a consultant to optimize what was perfectly good code before the table size grew.
Opinions on the Twiddler2 hand-held keyboard?
Sarcasm or not, I half agree with that.
Today's problem isn't that databases are bad, it's that we use a textual language to interface with databases, and it blurs the line between data and code.
SQL sucks.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
RTFA geez. The artitcle was not about postreSQL, it merely mentioned it. He didn't slam it at all or even state that you shouldn't use it. Simply said that if desired you may be able to avoid using it and emulate missing features of mySQL using php. He was illustrating the capabilities of php, not slamming postreSQL. By the way, many hosting providers provide mySQL but not postgreSQL so it may be useful to work around not having it.
Where did the title for this slashdot post come from? The couple sentences that mentioned postreSQL? What about the rest of the article? Stop being drama-queens. Slashdot needs more serious posts- not this flame-inducing crap.
It shouldn't be necessary to say that, but unfortunately it is. When I took Computer Science 100 in college 30+ years ago, the first lesson about inputting data was that you have to validate it before using it, because it's guaranteed that your program *will* be given bad data sometimes, and will occasionally be given maliciously bad data, and part of the grading process on programs was to run them on the professor's data set, which was malicious, especially at testing off-by-one errors and other boundary conditions. But enough other people didn't get that as part of their education, either in school or learning it the hard way in practice - sigh.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Couldn't be more correct. I've done a little PHP hacking when I'd no other choice--it's to be avoided when possible. For what it was meant for initially, it's not too shabby, but as a general solution it's...lacking.
It's not really surprising that the author of PHP would think that the things PostgreSQL buys you aren't worth it. You know, little things like integrity, reliability and stability. Who needs those? Not anyone writing in PHP, certainly.
Play around with ACID, and you're liable to take a header out the window !!
Dude, that's another kind of ACID. It's database ACID (Atomicity, Consistency, Isolation, and Durability), not the stuff that people got high on in the sixties. Concerning the latter, there actually have been unsubstantiated rumors about people who imagined they could fly and took a dive through the window.
I used to be a sceptic. These days, I'm not so certain.
The creators of PHP are morons, and their support company Zend is dishonest and incompetent. The ZActiveRecord boondoggle demonstrates exactly what I mean: They can't program their way out of a paper bag, an don't even understand the limitations of the very language that they haphazardly "designed".
It makes me laugh that Lerdorf would slam Postgres, because the PHP designers have no understanding of object oriented programming or databases: instead they invent half baked cargo-cult designs, which are naive reactions to other systems they don't understand: they try to ape their surface features without understanding the reasons behind the way they're designed.
PHP references were thrown in as a band-aid to work around the horrible design flaw that arrays and objects were foolishly DEEP COPIED by default. If you pass or return an array from function to function, its contents are DEEP COPIED, which is EXTREMELY inefficient and leads to all kinds of horrible bugs because it's the last thing a sane programmer would expect. So instead of fixing the design flaw in PHP, they add "references" that LOOK and SOUND like C++ references, but actually are completely different, again misleading programmers into thinking they understand what's going on, but working totally differently than a sane person would expect. PHP references are actually half baked symbol table references. The sloppy implementation caused many bugs that CORE DUMP PHP! PHP references were so poorly thought out and badly designed, that there were many edge conditions that they hadn't considered, that simply didn't work together, caused memory leaks and core dumps, and had useless and confusing semantics: callers passing references, functions declaring that they take references, functions returning references, etc. Compare that to C++'s simple and consistent definition of references in term of pointers. The only way to make a PHP reference to an object is to put it in a variable -- you can't make a reference to a field of an object or the return value of a function without storing it in a temporary variable -- totally unlike C++, and totally stupid.
PHP's object oriented programming system is a half-baked imitation of C++'s object model, haphazardly designed by charlitans who had no clue about the fundamentals of object oriented programming, elegant language design or efficient implementation. First of all, if you're going to try to imitate an existing design without understanding it, then for god's sake, at least imitate a language whose object system doesn't suck, and a language that has similar semantics to the language you're trying to kludge. C++ is a static compiled language, and its object system deeply reflects that fact. (That is to say, there's very little reflection beyond RTTI, because the compiler throws all the interesting stuff away! And C++'s oop design had to make many horrible compromises because the C++ object system was designed to map directly into C semantics [since the original C++ compiler compiled C++ into C.]) Most of those C++ design decisions make absolutely no sense for a dynamic interpreted language like PHP. (Many of them made very little sense for C++ itself, but even less sense in the context off PHP.)
One prime example of how PHP screwed up its object system, is that they blew it on static methods, in a way that makes it impossible to properly implement an ActiveRecord-like ORM (among other us
Take a look and feel free: http://www.PieMenu.com
Switch out your Postgresql database for a Mysql database running on speedy ISAM tables.
VROOOOOOOOOMMMMMMMMMMMMMMM!
Is that the sound of your database speeding up, or your data integrity disappearing?
Only Rasmus Lerdorf really knows...
"magic quotes" was, is and will forever be a terrible idea.
It is one of the many PHP misfeatures that make it easy for programmers to do the WRONG THING.
The correct way to do things is to filter/quote inputs to your program accordingly so that your program can handle them correctly.
Then you filter/quote outputs from your program to other programs accordingly so that those programs can handle the outputs correctly.
If you don't do that you will end up with corrupted or misinterpreted data or worse.
The correct filtering/quoting for an Oracle database is different from that for MySQL, and is different for a web browser, and for syslog.
Magic quotes combines all the quoting with one "easy" "fix", and because of this sort of wrong-minded thinking, plenty of sites are littered with spurious backslashes in their content.
There are plenty of other things PHP does wrong, and a lot of those are PHPisms - the things that make PHP PHP. By the time they fix those, PHP ends up not like PHP. Go look at the "backtracking" changes from PHP3 to PHP5.
You might as well skip all that crap and go with some other programming language - like python, perl, ruby.
BTW the same goes for MySQL, look at the changes from MySQL3 to MySQL5. MySQL3 = "Oh you don't really need transactions at all". MySQL4, "use transactions if you don't need speed". MySQL5 "oh yeah quietly corrupting data by default is a bad idea after all".
With PHP/MySQL 3 to 5, if you leave the defaults on, lots of things break, because the old way of doing things was a bad idea e.g. register_globals=on.
With Postgresql, the direction and principles have remained pretty much the same over the years- just getting better and better. So if you have written a program for postgresql 6.5, you can pretty much upgrade to 8.1 and your app will usually work by _default_ and work faster too.
You mean like when they supported Windows 98 up until July 11, 2006?
no comment
It does, but that's really a different matter.
Under MSSQL, there's no way of reading stuff from a table and not having the possibility of blocking something else or getting blocked. It's a trivial mistake to make, open the Enterprise Manager, load a big view or table and leave it open. The darn thing will keep a lock on the table unless you scroll down to the bottom of the result list.
You can use the WITH(NOLOCK) hint, but that's crap, as now you get uncommitted data in your SELECT.