# mysql_escape() issue (Was: RFC: ext/mysql deprecation) - Thread: https://externals.io/message/63924 - Original archive: https://news-web.php.net/php.internals/63924 - Started by Patrick ALLAERT on 2012-11-16T10:18:31+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #63924 — Patrick ALLAERT — 2012-11-16T10:18:31+00:00 URL: https://externals.io/message/63924#63924 2012/11/12 Adam Harvey : > 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 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. > > 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 ? [1] https://github.com/ezsystems/ezpublish/compare/e00a2c5cfef6776e0b8d8a330b1f6cb397b1ec0e~...485c7054e2f6a381f6f562797e6d0c1cce2c59f2 Patrick --- ## #63930 — Rasmus Lerdorf — 2012-11-16T16:26:06+00:00 URL: https://externals.io/message/63924#63930 · In reply to: #63924 > 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 --- ## #63931 — Patrick ALLAERT — 2012-11-16T17:32:02+00:00 URL: https://externals.io/message/63924#63931 · In reply to: #63930 2012/11/16 Rasmus Lerdorf : > > > […] > > 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. --- ## #63932 — Rasmus Lerdorf — 2012-11-16T17:42:33+00:00 URL: https://externals.io/message/63924#63932 · In reply to: #63931 > 2012/11/16 Rasmus Lerdorf : > > […] > > 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 --- ## #63933 — Patrick ALLAERT — 2012-11-16T17:50:22+00:00 URL: https://externals.io/message/63924#63933 · In reply to: #63932 2012/11/16 Rasmus Lerdorf : > > > […] > > 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.