You're wrong

First of all, mysql extension is out-of-date. It does not support many of the new features of the MySQL 5.x+ database:
* does not allow to create prepared statements (potential security issue),
* does not like i18n (potential SQL sanitization problems),
* does not support stored procedures
* cannot read multiple-results from one query (returned from stored procedures, etc),
* does not offer multiquery functionality (slow batch queries)
etc...

Those were the missing features.

You may say: "so what, don't fix what isn't broken".

Well, majority of the old PHP software which uses the mysql extension has some potential security holes:
* because it uses the mysql_escape_string or mysql_real_escape_string selectively...
* because of the potential incompatibilities with new versions of MySQL (MySQL 5.x is not 100% compatible with your software so you often stick to the old, buggy 4.1.x and 4.0.13 db's),
* because your software runs smoothly only on the old 5.1, and 5.0 PHP's (there are some minor incompatibilities with newer versions of PHP, like this: http://www.php.net/manual/en/migration51.references.php, http://www.php.net/manual/en/migration53.deprecated.php, etc)
* because your boss does not understand why he should pay you extra money for fixing something, that works fine, and tells you to not to change anything or don't test any new versions of MySQL/PHP.

Conclusion: If your software is old, you are forced to test it against any new version of PHP/MySQL if you want to update the system software.

If you fail the test and don't want to rewrite your db layer, you can make some simple code changes: disable the deprecated MySQL extension entirely (so you can implement your own mysql_connect() function, etc), write your own MySQL wrapper in PHP (which uses PDO internally) and include it using the "auto_prepend_file" directive.

I think it's two days work to make your own MySQL wrapper.

From the Zend Core developers point of view: removing one deprecated library = less time spent on maintaing legacy code = more time for new development, improvement and new features = more security in PHP.

You are talking about the ideal world on which every site owner has unlimited time and money to spend on fixing code of sites which are not broken.

Unfortunately the real world is very different from that. Maybe you did not think about those with limited budget to make any changes, if they ever have a clue that they really need to make the changes.

I dont see how expensive are two days of work to write a PHP wrapper simulating mysql extension, just like that:

function mysql_connect(...) {
$pdo = new PDO(...);
...
}

I'm not talking about an ideal world, I work for over 8 years for major Polish coroporations, which do not like to spend money on things that aren't broken. They want to invest the cach in new features, and marketing. Neverthless there was always time and bugdet to fix some deprecated warnings because PHP core team forced our managing board to find some cash, because "it is vital to update PHP to newer versions because of the security reasons". If PHP dev team would not mark something as deprecated/disable some old extensions, I would not have time/budget to make our software better and more secure.

If you like to stay with your old, buggy software "because it works" (even if it's insecure and expensive to maintain) it's your choice, but don't encourage others to be mediocree and ignorant to the security and research/development problems. After all, you dont watch the TV on the black&white TV set from early 60's because it's working, so why do you want to stay with old software? Just look what lulz and anonymous done to some of the websites, and read some (unfair) opinions about PHP and its security/legacy problems compared to Python/Ruby.

It's all the matter of quality. If your project is well builded you will have no problem with exchanging db engine or creating small script that will make changes to your code. But if your project is poorly designed deprecation of mysql extension is a disaster for you.

Problem with php applications is that most of them is poorly designed and that's why so many people complain about incompatibilities between php4 and php5.

In my opinion trying to make php5 and later versions backward compatible isnt the best idea. It would be a lot better if new php versions would be fully object oriented. I would divide php into branches 4.x and 5+. versions prior to 5 would be old style. Versions 5 and later object oriented with all functions agregated into classes and placed in php namespace.

And about real world - if you don't have money to upgrade your software you don't have to upgrade php. If you want to use old code then stick to old versions of php (i know - bugs, holes etc - it is your choice).

Well, fact is that the original mysql extension already is deprecated and superseeded, it is simply not marked as such. It is time to change that.

You say that people will be afraid of the new deprecated notices, but those people with little money you are speaking about should not be seeing these warnings. People that don't have the money to change the code should only have the code in a production enviroment. If an production enviroment shows you notices, I would consider this a bug in itself (caused by misconfiguration).

Site owners don't need "unlimited time and money", only a small finite amount. If they have the time and money to upgrade PHP, they also have the time and money to add a "auto_prepend_file = /foo/bar/wrapper_that_someone_else_has_already_written.php" to php.ini.

It's funny how the "time and money" of the documentation and mysql team doesn't matter though.

You can just not upgrade and face the security risks. If a site owner does not have time he can hire somebody or if he doesn't have money learn, there ain't no way around it. Deprecation is a normal fact in life, it was normal for php 4 to 5 and will be normal from 5 to 6, versions will most likely be incompatibile but that's ok.

And to answer your "You may ask: what was the point of that?" question, it's because OOP was becoming a real goal for PHP, and it had to drop may of it's old coding behaviours. It was the "nice" way of getting people to learn to properly code, getting more maintainable, secure and even faster code out the doors, instead of anyone doing whatever they want without a damn principle.

PHP is bloated enough already, the old mysql extension should be deprecated and removed ASAP, it's one of many such actions.

I think that a decision to create a software need to have future upgrades in consideration. If was not planned, it was a bad practice. Need to be revised and replanned. If upgrading crashes a software, don't upgrade unless it's broken. space shuttles went up with spectrums 48k supporting several systems because they were good and they did what expected. Banks use Cobol because it works, doesn't brake and simply do what needed to be done.

If you upgrade just because you want the latest, bleeding edge version, then prepare to refactor. This has been like this since the beggining of computers. This was what happened in 2000 with the crazy bug. Software was broken so let's upgrade and refactor.

I think that working OOP and use something like an Model View controller will allow developers to switch smoothly to newer versions or different database engines. I have all my connection scripts in one directory called model. This model consists of one parent abstract DBengine class with mysql functions. For each action (select update delete insert etc). The childclasses contain specific languages for each model (creating query's, process data etc. In my case it will only cost me a few hours to change my abstract class...

I agree with Manuel on this point. While the original mysql extension does not support the more advanced features of the 5.x engine, the time and effort (and potential bugs introduced by touching already tried and tested code) don't seem like a good idea.

Personally, I started using mysqli for new projects but didn't modify (and hopefully won't have to) any existing code that used the original library, unless my clients requested me to.