2012/11/12 Adam Harvey aharvey@php.net:
Hi everyone,
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 generatingE_DEPRECATEDnotices 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.I must apologise for the lateness of this RFC: I had hoped to do this
some time before alpha 1, but travel and illness have taken their
toll. Better late than never!So, please provide comments, feedback, concerns, and so on. Obviously,
this isn't going to a vote for at least a couple of weeks, but earlier
feedback is better.Thanks,
Adam
--
There is one remaining issue if ext/mysql is being deprecated (only by
having E_DEPRECATED in mysql_connect()/mysql_pconnect() and then
removed later.
People using mysql_escape() only to generate SQL files would never see
the deprecation and the function would suddenly be removed.
Technically, this could be solved by setting a global flag that is
reset at RINIT while all mysql_* functions would emit the E_DEPRECATED
notice if the global flag is not yet set (a singleton like pattern).
While this is technically possible, we should still cover the
following use case: make it possible to generate valid queries while
not being able to connect to any MySQL server yet.
In eZ Publish CMS, we have recently removed [1] support for the mysql
handler in favour of the mysqli one and as such, we have no more
mysql_*() functions calls except for the above use case where we rely
on mysql_escape().
Opinions ?
Patrick
In eZ Publish CMS, we have recently removed [1] support for the mysql
handler in favour of the mysqli one and as such, we have no more
mysql_*() functions calls except for the above use case where we rely
on mysql_escape().
I suppose you mean mysql_real_escape_string() here. There is no
mysql_escape() function and mysql_escape_string() is already marked as
deprecated as of 5.3.
-Rasmus
2012/11/16 Rasmus Lerdorf rasmus@lerdorf.com:
In eZ Publish CMS, we have recently removed [1] support for the mysql
handler in favour of the mysqli one and as such, we have no more
mysql_*() functions calls except for the above use case where we rely
on mysql_escape().I suppose you mean mysql_real_escape_string() here. There is no
mysql_escape() function and mysql_escape_string() is already marked as
deprecated as of 5.3.-Rasmus
Sorry, I meant mysql_escape_string().
I missed the fact it was already deprecated and as such, we have an
issue here in our code base since nor mysql_real_escape_string() nor
mysqli_real_escape_string() fits our use case as we are using it when
we have to generate an SQL file with queries to be executed on another
box. Not having access to a database prevents us to have a link which
is required by those functions.
2012/11/16 Rasmus Lerdorf rasmus@lerdorf.com:
In eZ Publish CMS, we have recently removed [1] support for the mysql
handler in favour of the mysqli one and as such, we have no more
mysql_*() functions calls except for the above use case where we rely
on mysql_escape().I suppose you mean mysql_real_escape_string() here. There is no
mysql_escape() function and mysql_escape_string() is already marked as
deprecated as of 5.3.-Rasmus
Sorry, I meant mysql_escape_string().
I missed the fact it was already deprecated and as such, we have an
issue here in our code base since nor mysql_real_escape_string() nor
mysqli_real_escape_string()fits our use case as we are using it when
we have to generate an SQL file with queries to be executed on another
box. Not having access to a database prevents us to have a link which
is required by those functions.
But without a link you don't know which charset the db is in and
therefore you can't reliably escape a query. In your case you can do a
custom escape thing based on the fact that you might know the
destination charset, but PHP on its own can't.
-Rasmus
2012/11/16 Rasmus Lerdorf rasmus@lerdorf.com:
2012/11/16 Rasmus Lerdorf rasmus@lerdorf.com:
In eZ Publish CMS, we have recently removed [1] support for the mysql
handler in favour of the mysqli one and as such, we have no more
mysql_*() functions calls except for the above use case where we rely
on mysql_escape().I suppose you mean mysql_real_escape_string() here. There is no
mysql_escape() function and mysql_escape_string() is already marked as
deprecated as of 5.3.-Rasmus
Sorry, I meant mysql_escape_string().
I missed the fact it was already deprecated and as such, we have an
issue here in our code base since nor mysql_real_escape_string() nor
mysqli_real_escape_string()fits our use case as we are using it when
we have to generate an SQL file with queries to be executed on another
box. Not having access to a database prevents us to have a link which
is required by those functions.But without a link you don't know which charset the db is in and
therefore you can't reliably escape a query. In your case you can do a
custom escape thing based on the fact that you might know the
destination charset, but PHP on its own can't.
We are defining the charset used at the beginning of the generated
file and wish it could be possible to pass the charset rather than a
link which is what is really needed.
Looks like a valid feature request to me. Would make sense only for
the procedural call of course. The first argument could then be a
resource or a string.