Angel On Thu, Nov 29, 2012 at 12:02 PM, Ángel González <keis...@gmail.com> wrote:
> David Muir wrote: > > On 29/11/12 05:09, Ángel González wrote: > >> I see it as simple to show E_DEPRECATED but not when installed from > >> PECL. > >> > >> 1) Add a > >> int mysql_extension_triggers_deprecated_warning = 1; > >> > >> And use it as a conditional for triggering the warning. > >> > >> 2) Copy the extension code to PECL > >> > >> 3) Add these changes in PECL > >> - If the mysql functions are not already registered, > >> register them with the bundled code. > >> - Set mysql_extension_triggers_deprecated_warning = 0; > >> > >> 4) That's it. > >> > > > > Then people (distros, hosts, etc) will just install it from PECL > > instead to avoid all the E_DEPRECATED mess. > > > > David > That's the goal. > If they really want the extension they can install it from PECL and they > don't get the E_DEPRECATED since that's not coming from core. > > No triggers-warning, moves-to-PECL, no-longer-triggers. > > It also provides a supported procedure for installing ext/mysql other > than patching php to skip the warning. When someone complains about how > they can only use ext/mysql (eg. they are using a code-protected script > which uses ext/mysql and is critical for their business...), you can > point to PECL, as well as explaining how it doesn't have the same > guarantees as php core. Just pointing this out: that's NOT what this RFC recommends, and is NOT what's being voted on. This RFC is talking about ONLY adding E_DEPRECATED to core. And the way it's proposed to be done, the "moves-to-PECL" couldn't happen, since it's hard-coded into the core extension... So be careful what you're voting for...
