On 11/12/2012 9:22 AM, Derick Rethans wrote:
On Mon, 12 Nov 2012, Adam Harvey wrote:
I've written an RFC to cover deprecating ext/mysql in PHP 5.5:
https://wiki.php.net/rfc/mysql_deprecation. While we handled the soft
deprecation in the documentation purely via a straw poll on Internals,
I presume this will end up needing to go to a vote, hence the RFC.
I won't rehash the background overly (there's some more detail in the
RFC), other than to note that we've now had deprecation notices on all
mysql_* functions in the manual for about six months and that the
logical next step is to start generating E_DEPRECATED notices when
users connect via mysql_connect(), mysql_pconnect() or the implicit
ext/mysql connection routines. It's my belief that doing so will
hasten the move of users to the more modern (and supported) APIs
available: mysqli and PDO, and that this process will also likely
encourage some users to switch to safer patterns such as prepared
queries at the same time.
IMO, there doesn't need to be a discussion on *how* to deprecate
ext/mysql. We have E_DEPRECATED for that, just like you write in your
RFC. The only question is "do we want
to deprecate it?". On that one: +1
cheers,
Derick
-1
Why deprecate? Just because you like PDO doesn't mean everyone else
will like it. Just because mysql_query() tends to create security
vulnerabilities in the hands of the uneducated who have the tendency to
string concatenate SQL queries together in an unsafe fashion, doesn't
mean users won't write insecure code with PDO. Users are lazy - binding
each field separately is going to drive some to resort to string
concatenation, which will result in a situation nearly identical to what
you have already. In the hands of someone who knows what they are
doing, ext/mysql is the same as, if not better than, mysqli and PDO.
The documentation on PDO is structured such that it attempts to pick off
SQL injection vulnerabilities up front. That's great and wonderful, but
the mysql_...() docs could easily get the same treatment. You have a
stable library in ext/mysql that's been hammered out over the years.
You're throwing out perfectly good code.
That's my opinion though. I generally agree with PDO because it will
result in fewer vulnerabilities in the hands of most newbie programmers.
I've seen enough bad code against ext/mysql to know that PDO is a good
thing. I'm ultimately willing to rewrite code if you force the issue.
The real problem: "PHP and MySQL go together" is a fundamental thought
that's been around a long time. There are even popular acronyms
dedicated to this thought: LAMP. The reason it has taken so long to do
anything about ext/mysql is because of this one central thought. So the
real question people are asking is, "Do we deprecate and get rid of a
fundamental thought?" If you are going to do this, just get rid of the
functions altogether and don't deprecate. It will be a lot less
painful. People will yell but they will rewrite their code if you want
everyone using PDO. The problem with ext/mysql is a psychological one,
not a technological one. If you want the transition period to be less
painful, write wrapper functions in userland PHP that uses PDO behind
the scenes that have the same names and parameters as the original
ext/mysql functions. Stick them in PEAR and throw deprecation warnings
on the PEAR repo so the user sees them when they install the wrapper.
IMO, very few, if any, extensions should be enabled by default.
Including them by default implies they should be in the core, not some
extension.
--
Thomas Hruska
CubicleSoft President
Barebones CMS is a high-performance, open source content management
system for web developers operating in a team environment.
An open source CubicleSoft initiative.
Your choice of a MIT or LGPL license.
http://barebonescms.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
