[VOTE] ext/mysql deprecation in 5.5 View as Markdown

All,

I've moved the ext/mysql deprecation RFC into the voting phase. You
can vote at https://wiki.php.net/rfc/mysql_deprecation — note that, as
discussed last week, there are two questions: the first being a simple
yes/no question (which will determine whether the RFC is accepted or
rejected), and the second to clarify what the preferred course of
action will be if the RFC is declined. Please vote on both, unless you
particularly wish to abstain from one of the questions.

I've also updated the RFC slightly, but not in a way that changes
what's actually proposed: Ulf noted that he wasn't comfortable with
having the Oracle Wiki link there for converting to MySQLi, so I've
replaced that link with another, more recent tutorial (albeit PDO
only) and added a link to Ulf's recent blog post about the benefits of
mysqli and PDO over ext/mysql. This is mostly useful for documentation
purposes, since I think there's general agreement that we should have
more resources covering upgrading to newer extensions regardless of
the outcome of this RFC.

At this stage, I intend to close the vote in a week's time: so
Wednesday, December 5.

Thanks,

Adam, who knows he's a little late with this, but being sick sucks. Sorry.

• Users will get warnings on upgrading - it can not be hidden by
  hosters/distros etc.

Think you might be wildly underestimating the ability of both distros
and stuff like cPanel to patch the extension. Then again - I think
everybody might be.

hi Alan!

.. annoying top posting...

Why do you top post too then? :)

This is getting close to a good solution.

ini option mysql_is_deprecated - can not be set in .ini/htaccess etc, only
by ini_set() - so hosters/distros can not fix it...

Are you asking to add an option to do exactly the same than the error
reporting option does?

Normally added just before mysql_connect...

ini_set('mysql_is_deprecated', "I WILL NOT USE IT IN THE FUTURE");

eror_reporting(...);

mysql_connect(......)

Solves:

• Users will get warnings on upgrading - it can not be hidden by
  hosters/distros etc.
• Users can easily disable the warning, however they will be explicitly
  aware of the problem.

Warning on install, on connect and in the doc is not enough? :) And
once it is on pecl, we have the superseded/deprecated flag too there.
It won't help for distros but distros will follow app leads, as usual.
The only reason why distros still provide ext/mysql by default is
because the apps require it by default.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Angel

David Muir 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...

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...
The RFC doesn't state if/when ext/mysql should be moved to pecl or if it
should or not throw E_DEPRECATED there.
It was stated in one of the previous threads that:

• The extension would be moved to PECL when removed from core.
• It's ok if you want to use ext/mysql from pecl as it's "unsupported"
  and your own problem, not one of php developers.

There were also concerns that throwing E_DEPRECATED didn't allow to
cleanly use it (if you really wanted to) as if it was simply moved to
pecl.

I was presenting a way to throw E_DEPRECATED (assuming that option wins
in the RFC) while also allowing an extension (typically hosted on PECL)
to “provide” the non-E_DEPRECATED extension.

If you take a closer look, you will see that it can happen, as long as
the core deprecation is done in that way, anticipating usage of that
pecl extension. (Note that it is a variable which could only be changed
by another extension, I wasn't proposing the ini_set mentioned by Alan,
IMHO that's an uglier solution, since everybody would end up setting it).

You are of course welcome to point out any failures in the pseudo-code I
presented. :)
There would be a dependency on ELF-like binaries if using weak symbols.
But the version removing ext/mysql will likely have a different ABI
anyway, so it's not a big problem to require a recompile of pecl/mysql
for the different php version.

This is exactly why it doesn't make sense to have a vote on E_DEPRECATED
without understanding what the future action will be.

I might have missed some as there was no summary of the discussion in
the RFC, or a summary of the various positions. This should have been
added before calling a vote. Combined with future action, the various
positions as I've read them are:

1. Throw E_DEPRECATED in 5.5. Move to PECL in 5.NEXT and stop throwing
   E_DEPRECATED
2. Throw E_DEPRECATED in 5.5. Move to PECL in 5.NEXT and continue
   throwing E_DEPRECATED
3. Move to PECL in 5.5 or 5.NEXT, and not throw E_DEPRECATED
4. Throw E_DEPRECATED in 5.5. Remove from core and PECL in 5.NEXT

#1 means it's not really being deprecated
#2 kind of makes sense, but then why even move it to PECL?
#3 is consistent with current release RFC process
#4 is the type of case E_DEPRECATED is meant to handle (or has handled
thus far)

The current release process RFC states:

  *
    *x.y.z to x.y+1.z*
      o
        Bugfixes
      o
        New features
      o
        *Extensions support can be ended (moved to pecl)*
      o
        Backward compatibility must be kept
      o
        API compatibility must be kept (userland)
      o
        ABI and API can be broken (internals), src compatibility
        should be kept if possible, while breakages are allowed

[emphasis mine]

Some are saying that that E_DEPRECATED can/should be used for entire
extensions. That's fine and dandy if said extension is actually going to
be removed (not just retired to PECL, but dropped completely), but
somehow I think a lot more people would object to the current RFC if
that were the plan.

Cheers,
David

I don't think it would be appropriate to remove ext/mysql (whether
completely or just moved to PECL) at any point in the 5.x branch. My
thinking is that 6.0 would be the time for major changes/BC like that to
take place. Since that's probably still a ways off, my understanding was
that we're limiting the scope to what should happen in 5.x in the form of
deprecation/transition. If you don't think it should be [re]moved at all,
then I would assume you'd want to vote no on deprecation anyway. And if
you do think it should be taken out in some form or another, then either
way deprecation prior to doing so would be the most sensible approach
IMNSHO. That's why it seems logical to me that we first decide on
when/whether to deprecate, then as we get closer to the next major version
increment we can figure out how best to dispose of it (assuming we voted to
deprecate in the first place).

--Kris

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...
The RFC doesn't state if/when ext/mysql should be moved to pecl or if it
should or not throw E_DEPRECATED there.
It was stated in one of the previous threads that:

• The extension would be moved to PECL when removed from core.
• It's ok if you want to use ext/mysql from pecl as it's "unsupported"
  and your own problem, not one of php developers.

There were also concerns that throwing E_DEPRECATED didn't allow to
cleanly use it (if you really wanted to) as if it was simply moved to pecl.

I was presenting a way to throw E_DEPRECATED (assuming that option wins
in the RFC) while also allowing an extension (typically hosted on PECL)
to “provide” the non-E_DEPRECATED extension.

If you take a closer look, you will see that it can happen, as long as
the core deprecation is done in that way, anticipating usage of that
pecl extension. (Note that it is a variable which could only be changed
by another extension, I wasn't proposing the ini_set mentioned by Alan,
IMHO that's an uglier solution, since everybody would end up setting it).

You are of course welcome to point out any failures in the pseudo-code I
presented. :)
There would be a dependency on ELF-like binaries if using weak symbols.
But the version removing ext/mysql will likely have a different ABI
anyway, so it's not a big problem to require a recompile of pecl/mysql
for the different php version.

This is exactly why it doesn't make sense to have a vote on E_DEPRECATED
without understanding what the future action will be.

I might have missed some as there was no summary of the discussion in
the RFC, or a summary of the various positions. This should have been
added before calling a vote. Combined with future action, the various
positions as I've read them are:

1. Throw E_DEPRECATED in 5.5. Move to PECL in 5.NEXT and stop throwing
   E_DEPRECATED
2. Throw E_DEPRECATED in 5.5. Move to PECL in 5.NEXT and continue
   throwing E_DEPRECATED
3. Move to PECL in 5.5 or 5.NEXT, and not throw E_DEPRECATED
4. Throw E_DEPRECATED in 5.5. Remove from core and PECL in 5.NEXT

#1 means it's not really being deprecated
#2 kind of makes sense, but then why even move it to PECL?
#3 is consistent with current release RFC process
#4 is the type of case E_DEPRECATED is meant to handle (or has handled
thus far)

It has been discussed to death. PECL provides superseded status, and
leaving the flag untouched is rather logical.

Can we stop this insane and repeatitve discussion and focus on having
the flag or not? we have enough time to figure out which option fits
best in the next release.

Cheers,

Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org