Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63924
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
MIME-Version: 1.0
Sender: patrick.allaert@gmail.com
Date: Fri, 16 Nov 2012 11:18:31 +0100
Message-ID: <CACwt+JeJ-H0e+MB-d7skTejoksCsHShB7_U8z1ke7EYWZ=-pWw@mail.gmail.com>
To: Adam Harvey <aharvey@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: mysql_escape() issue (Was: [PHP-DEV] RFC: ext/mysql deprecation)
From: patrickallaert@php.net (Patrick ALLAERT)

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 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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