FAQ
Greetings PHP geeks,

Don't panic! This is not a proposal to add errors or remove this popular extension. Not yet anyway, because it's too popular to do that now.

The documentation team is discussing the database security situation, and educating users to move away from the commonly used ext/mysql extension is part of this.

This proposal only deals with education, and requests permission to officially convince people to stop using this old extension. This means:

- Add notes that refer to it as deprecated
- Recommend and link alternatives
- Include examples of alternatives

There are two alternative extensions: pdo_mysql and mysqli, with PDO being the PHP way and main focus of future endeavors. Right? Please don't digress into the PDO v2 fiasco here.

What this means to ext/mysql:

- Softly deprecate ext/mysql with education (docs) starting today
- Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
- Add pdo_mysql examples within the ext/mysql docs that mimic the current
examples, but occasionally introduce features like prepared statements
- Focus energy on cleaning up the pdo_mysql and mysqli documentation
- Create a general "The MySQL situation" document that explains the situation

The PHP community has been recommending alternatives for several years now, so hopefully this won't be a new concept or shock to most users.

Regards,
Philip

Search Discussions

  • Reindl Harald at Jul 10, 2011 at 5:15 pm

    Am 10.07.2011 19:03, schrieb Philip Olson:
    What this means to ext/mysql:

    - Softly deprecate ext/mysql with education (docs) starting today
    - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
    - Add pdo_mysql examples within the ext/mysql docs that mimic the current
    examples, but occasionally introduce features like prepared statements
    - Focus energy on cleaning up the pdo_mysql and mysqli documentation
    - Create a general "The MySQL situation" document that explains the situation

    The PHP community has been recommending alternatives for several years now,
    so hopefully this won't be a new concept or shock to most users
    sounds reasonable and i would love to be not forced loading
    "mysql.so" AND "mysqli.so" because some peopole are using
    legacy code and unwilling to maintain their stuff
  • Mike Robinson at Jul 10, 2011 at 8:20 pm

    On July-10-11 1:16 PM Reindl Harald wrote:
    Am 10.07.2011 19:03, schrieb Philip Olson:
    What this means to ext/mysql:

    - Softly deprecate ext/mysql with education (docs) starting today
    - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
    - Add pdo_mysql examples within the ext/mysql docs that mimic the
    - current examples, but occasionally introduce features like
    - prepared statements
    - Focus energy on cleaning up the pdo_mysql and mysqli documentation
    - Create a general "The MySQL situation" document that explains the
    - situation

    The PHP community has been recommending alternatives for several
    years now, so hopefully this won't be a new concept or shock to most
    users
    sounds reasonable and i would love to be not forced loading
    "mysql.so" AND "mysqli.so" because some peopole are using
    legacy code and unwilling to maintain their stuff

    Sure, some users in the PHP community are aware of this desire.

    We're talking about tons of developers, vast amounts of legacy code
    written over 2 decades - longer than many in that same community have
    been alive.

    Most developers "out there" are not remotely aware of this.

    IMHO, it doesn't matter how early the education gets started or how
    much time and sugar is used to coat this, it'll be a bitter pill for
    a very large group of people.

    This needs to be thought out very carefully.

    Best Regards,

    Mike Robinson
  • Pierre Joye at Jul 10, 2011 at 9:01 pm
    hi,

    As I would love to kill ext/mysql, it is up to the mysql developers to decide.

    Cheers,
    On Sun, Jul 10, 2011 at 7:03 PM, Philip Olson wrote:
    Greetings PHP geeks,

    Don't panic! This is not a proposal to add errors or remove this popular extension. Not yet anyway, because it's too popular to do that now.

    The documentation team is discussing the database security situation, and educating users to move away from the commonly used ext/mysql extension is part of this.

    This proposal only deals with education, and requests permission to officially convince people to stop using this old extension. This means:

    - Add notes that refer to it as deprecated
    - Recommend and link alternatives
    - Include examples of alternatives

    There are two alternative extensions: pdo_mysql and mysqli, with PDO being the PHP way and main focus of future endeavors. Right? Please don't digress into the PDO v2 fiasco here.

    What this means to ext/mysql:

    - Softly deprecate ext/mysql with education (docs) starting today
    - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
    - Add pdo_mysql examples within the ext/mysql docs that mimic the current
    examples, but occasionally introduce features like prepared statements
    - Focus energy on cleaning up the pdo_mysql and mysqli documentation
    - Create a general "The MySQL situation" document that explains the situation

    The PHP community has been recommending alternatives for several years now, so hopefully this won't be a new concept or shock to most users.

    Regards,
    Philip


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php


    --
    Pierre

    @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
  • Matthew Weier O'Phinney at Jul 11, 2011 at 2:28 pm

    On 2011-07-10, Philip Olson wrote:
    Greetings PHP geeks,

    Don't panic! This is not a proposal to add errors or remove this
    popular extension. Not yet anyway, because it's too popular to do that
    now.

    The documentation team is discussing the database security situation,
    and educating users to move away from the commonly used ext/mysql
    extension is part of this.

    This proposal only deals with education, and requests permission to
    officially convince people to stop using this old extension. This
    means:

    - Add notes that refer to it as deprecated
    - Recommend and link alternatives
    - Include examples of alternatives

    There are two alternative extensions: pdo_mysql and mysqli, with PDO
    being the PHP way and main focus of future endeavors. Right? Please
    don't digress into the PDO v2 fiasco here.

    What this means to ext/mysql:

    - Softly deprecate ext/mysql with education (docs) starting today
    - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
    - Add pdo_mysql examples within the ext/mysql docs that mimic the
    current examples, but occasionally introduce features like prepared
    statements
    - Focus energy on cleaning up the pdo_mysql and mysqli documentation
    - Create a general "The MySQL situation" document that explains the
    situation

    The PHP community has been recommending alternatives for several years
    now, so hopefully this won't be a new concept or shock to most users.
    Big +1 from me. We actually chose not to do a Mysql adapter in Zend_Db
    primarily due to the security issues, but also due to the much more
    advanced feature sets available in the mysqli and pdo/mysql adapters.

    --
    Matthew Weier O'Phinney
    Project Lead | matthew@zend.com
    Zend Framework | http://framework.zend.com/
    PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
  • Adam Harvey at Jul 11, 2011 at 2:41 pm

    On 11 July 2011 01:03, Philip Olson wrote:
    What this means to ext/mysql:

    - Softly deprecate ext/mysql with education (docs) starting today
    - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
    - Add pdo_mysql examples within the ext/mysql docs that mimic the current
    examples, but occasionally introduce features like prepared statements
    - Focus energy on cleaning up the pdo_mysql and mysqli documentation
    - Create a general "The MySQL situation" document that explains the situation
    I'm hugely +1 on this. (Which won't be a shock to anyone on IRC.) It's
    time to start softening the user base up for the idea that, one day,
    ext/mysql will in fact go away, and probably won't be terribly
    mourned.

    Adam
  • Keloran at Jul 11, 2011 at 3:11 pm
    maybe we should get another E_, E_NEARLY_DEPRECATED that way we can set this
    to that, and then 5.5 we can move it to E_DEPRECATED, that way people have
    to go read the docs, the amount of people even those who have been in the
    field for years, that dont know about php.net/<func> and still look stuff up
    on google makes me wonder that no matter how soft you make the change by
    doing it in the docs, wont make that much difference to how people react to
    it being dropped
    On Mon, Jul 11, 2011 at 3:40 PM, Adam Harvey wrote:
    On 11 July 2011 01:03, Philip Olson wrote:
    What this means to ext/mysql:

    - Softly deprecate ext/mysql with education (docs) starting today
    - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
    - Add pdo_mysql examples within the ext/mysql docs that mimic the current
    examples, but occasionally introduce features like prepared statements
    - Focus energy on cleaning up the pdo_mysql and mysqli documentation
    - Create a general "The MySQL situation" document that explains the
    situation

    I'm hugely +1 on this. (Which won't be a shock to anyone on IRC.) It's
    time to start softening the user base up for the idea that, one day,
    ext/mysql will in fact go away, and probably won't be terribly
    mourned.

    Adam

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Christopher Jones at Jul 11, 2011 at 3:41 pm

    On 7/10/11 10:03 AM, Philip Olson wrote:

    What this means to ext/mysql:

    - Softly deprecate ext/mysql with education (docs) starting today
    - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
    - Add pdo_mysql examples within the ext/mysql docs that mimic the current
    examples, but occasionally introduce features like prepared statements
    - Focus energy on cleaning up the pdo_mysql and mysqli documentation
    - Create a general "The MySQL situation" document that explains the situation
    +1, though check with the MySQL folk about whether they want mysqli or pdo_mysql to
    be the recommended path.

    Chris

    --
    Email: christopher.jones@oracle.com
    Tel: +1 650 506 8630
    Blog: http://blogs.oracle.com/opal/
  • Paul Dragoonis at Jul 11, 2011 at 4:31 pm

    On Mon, Jul 11, 2011 at 4:41 PM, Christopher Jones wrote:

    On 7/10/11 10:03 AM, Philip Olson wrote:

    What this means to ext/mysql:

    - Softly deprecate ext/mysql with education (docs) starting today
    - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
    - Add pdo_mysql examples within the ext/mysql docs that mimic the current
    examples, but occasionally introduce features like prepared statements
    - Focus energy on cleaning up the pdo_mysql and mysqli documentation
    - Create a general "The MySQL situation" document that explains the
    situation
    +1, though check with the MySQL folk about whether they want mysqli or
    pdo_mysql to
    be the recommended path.

    Chris
    Yes, +1 from me too. I do indeed think we need to make this a smooth
    transition over time. Possibly triggering an E_DEPRECATED for all
    ext/mysql usage. Just like the introduction of E_DEPRECATED for 5.3
    functions, we could apply the same approach here. After 5.4 is
    released we can put big "Deprecated Warning" notifications on all
    php.net/mysql_* functions too. I think we all want this, but to be
    realistic from a production point of view, many sites will still be
    using ext/mysql.

    Regards,
    Paul Dragoonis.
    --
    Email: christopher.jones@oracle.com
    Tel:  +1 650 506 8630
    Blog:  http://blogs.oracle.com/opal/

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Matthew Weier O'Phinney at Jul 11, 2011 at 5:56 pm

    On 2011-07-11, Paul Dragoonis wrote:
    On Mon, Jul 11, 2011 at 4:41 PM, Christopher Jones
    wrote:
    On 7/10/11 10:03 AM, Philip Olson wrote:
    What this means to ext/mysql:

    - Softly deprecate ext/mysql with education (docs) starting today
    - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
    - Add pdo_mysql examples within the ext/mysql docs that mimic the current
    examples, but occasionally introduce features like prepared statements
    - Focus energy on cleaning up the pdo_mysql and mysqli documentation
    - Create a general "The MySQL situation" document that explains the
    situation
    +1, though check with the MySQL folk about whether they want mysqli or
    pdo_mysql to
    be the recommended path.

    Chris
    Yes, +1 from me too. I do indeed think we need to make this a smooth
    transition over time. Possibly triggering an E_DEPRECATED for all
    ext/mysql usage. Just like the introduction of E_DEPRECATED for 5.3
    functions, we could apply the same approach here. After 5.4 is
    released we can put big "Deprecated Warning" notifications on all
    php.net/mysql_* functions too. I think we all want this, but to be
    realistic from a production point of view, many sites will still be
    using ext/mysql.
    And, to my reading, this is exactly the path that was recommended. The
    point is to start a "soft" deprecation now via the manual, indicating
    that users should migrate to other solutions, while simultaneously
    detailing how to do equivalent operations via ext/mysqli or pdo_mysql.
    Actual deprecation would happen later.

    --
    Matthew Weier O'Phinney
    Project Lead | matthew@zend.com
    Zend Framework | http://framework.zend.com/
    PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
  • Mike Robinson at Jul 11, 2011 at 6:47 pm

    On July-11-11 Matthew Weier O'Phinney wrote:

    Sent: July-11-11 1:57 PM
    To: internals@lists.php.net
    Subject: Re: [PHP-DEV] deprecating ext/mysql

    On 2011-07-11, Paul Dragoonis
    Yes, +1 from me too. I do indeed think we need to make this a smooth
    transition over time. Possibly triggering an E_DEPRECATED for all
    ext/mysql usage. Just like the introduction of E_DEPRECATED for 5.3
    functions, we could apply the same approach here. After 5.4 is
    released we can put big "Deprecated Warning" notifications on all
    php.net/mysql_* functions too. I think we all want this, but to be
    realistic from a production point of view, many sites will still be
    using ext/mysql.
    And, to my reading, this is exactly the path that was recommended. The
    point is to start a "soft" deprecation now via the manual, indicating
    that users should migrate to other solutions, while simultaneously
    detailing how to do equivalent operations via ext/mysqli or pdo_mysql.
    Actual deprecation would happen later.
    I haven't looked at the mysql_* section of the manual in 15 years. It
    would not surprise me to learn that that was one of the least viewed
    areas of manual.

    I'd be curious to see what kind of response this suggestion would elicit
    from the PHP General list.

    From the MySQL site:

    "We have no plans to remove libmysql support from ext/mysql, ext/mysqli
    or PDO_MYSQL, which would break existing applications. We just add a new,
    superior alternative to our PHP offerings."

    So I'd also be interested to hear what the MySQL folks had to say about
    this.

    If a laissez-faire approach is taken a lot of people are going to have
    bite marks on their behinds.

    Mike
  • Larry Garfield at Jul 15, 2011 at 1:37 am

    On 07/10/2011 12:03 PM, Philip Olson wrote:
    Greetings PHP geeks,

    Don't panic! This is not a proposal to add errors or remove this popular extension. Not yet anyway, because it's too popular to do that now.

    The documentation team is discussing the database security situation, and educating users to move away from the commonly used ext/mysql extension is part of this.

    This proposal only deals with education, and requests permission to officially convince people to stop using this old extension. This means:

    - Add notes that refer to it as deprecated
    - Recommend and link alternatives
    - Include examples of alternatives

    There are two alternative extensions: pdo_mysql and mysqli, with PDO being the PHP way and main focus of future endeavors. Right? Please don't digress into the PDO v2 fiasco here.

    What this means to ext/mysql:

    - Softly deprecate ext/mysql with education (docs) starting today
    - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
    - Add pdo_mysql examples within the ext/mysql docs that mimic the current
    examples, but occasionally introduce features like prepared statements
    - Focus energy on cleaning up the pdo_mysql and mysqli documentation
    - Create a general "The MySQL situation" document that explains the situation

    The PHP community has been recommending alternatives for several years now, so hopefully this won't be a new concept or shock to most users.

    Regards,
    Philip
    A-frickin'-men! :-)

    Just today I was talking to a new developer in #PHP in IRC who had code
    with mysql_* calls in it. I don't know where he found them, but I told
    him to put them back where he found them right away and use PDO
    instead. That people are still learning ext/mysql in this day and age
    is quite sad.

    There's millions of lines of code out there we can't break yet, but we
    can absolutely structure documentation so that we don't produce even
    more PHP developers who mistakenly think that mysql_query() is a good idea.

    +1

    --Larry Garfield
  • Johannes Schlüter at Jul 15, 2011 at 12:47 pm
    Hi,
    On Sun, 2011-07-10 at 10:03 -0700, Philip Olson wrote:
    Greetings PHP geeks,

    Don't panic! This is not a proposal to add errors or remove this
    popular extension. Not yet anyway, because it's too popular to do that
    now.

    The documentation team is discussing the database security situation,
    and educating users to move away from the commonly used ext/mysql
    extension is part of this.
    Moving away from ext/mysql is not only about security but also about
    having access to all features of the MySQL database.

    ext/mysql was built for MySQL 3.23 and only got very few additions since
    then while mostly keeping compatibility with this old version which
    makes the code a bit harder to maintain. From top of my head missing
    features not support be ext/mysql include:
    * Stored Procedures (can't handle multiple result sets)
    * Prepared Statements
    * Encryption (SSL)
    * Compression
    * Full Charset support
    * ...
    *

    So moving away from ext/mysql is a good thing.
    This proposal only deals with education, and requests permission to
    officially convince people to stop using this old extension. This
    means:

    - Add notes that refer to it as deprecated
    - Recommend and link alternatives
    - Include examples of alternatives +1
    There are two alternative extensions: pdo_mysql and mysqli, with PDO
    being the PHP way and main focus of future endeavors. Right? Please
    don't digress into the PDO v2 fiasco here.
    I'm not sure the current PDO is "the" alternative. We (= MySQL/ORACLE)
    focus mostly on mysqli, that's the extension providing access to all
    current and future features of MySQL. True, many features could be added
    to PDO but there are two design decision in PDO which make this bad:

    * The parser used for identifying statement place holders is very
    basic, as it is implemented in PDO core, not the drivers, which
    leads to FRs like #54929 or the famous LIKE issue[1]
    * driver-specific functions are implemented by using __call()
    which means there is no good introspection mechanism to check
    whether a feature is available or not in the current setup.

    Besides these two items there are every now and then reports on
    PDO_mysql which in fact are caused by limitations in the PDO design
    which can't be bypassed by the driver implementation.

    A good abstraction layer would certainly be good for the language but
    for now we (=MySQL/ORACLE) consider mysqli the preference.
    What this means to ext/mysql:

    - Softly deprecate ext/mysql with education (docs) starting today
    - Not adding E_DEPRECATED errors in 5.4, but revisit for 5.5/6.0
    - Add pdo_mysql examples within the ext/mysql docs that mimic the current
    examples, but occasionally introduce features like prepared statements
    - Focus energy on cleaning up the pdo_mysql and mysqli documentation
    - Create a general "The MySQL situation" document that explains the situation
    I also want to point to http://forge.mysql.com/wiki/Converting_to_MySQLi
    wich has a script once developed by Ulf and others to automatically
    convert code from using ext/mysql to mysqli. I haven't tried it with
    recent versions of PHP but should still work.
    The PHP community has been recommending alternatives for several years
    now, so hopefully this won't be a new concept or shock to most users.
    :-)

    johannes


    [1] The LIKE case goes something like that:

    <?php
    $query = $pdo->prepare("SELECT id FROM table LIMT ?, ?");
    $query->bindValue(1, $_GET["offset"]);
    $query->bindValue(2, $_GET["limit"]);
    $query->execute();
    ?>

    So there's some pagination of a result set and the user can browse
    through the result, looks quite ok, but the result is not a successful
    query but an error

    1064 you have an error in oyur SQL sytax; check the manual that
    corresponds to your MySQK server version for the right syntax to
    use near ''1', '2''

    Which is caused by PDO using PS emulation by default with MySQL (see
    thread "Change Request: Make PDO default to not emulate prepared
    statements for MySQL" from April/May 2011 on this list) and $_GET
    containing strings while the parser is not context-aware. Of course this
    can easily be fixed by explicitly binding using PDO::PARAM_INT.

    --
    Johannes Schlüter, ORACLE
    MySQL Engineering - Connectors And Client Connectivity
  • Reindl Harald at Jul 15, 2011 at 12:56 pm

    Am 15.07.2011 14:46, schrieb Johannes Schlüter:

    ext/mysql was built for MySQL 3.23 and only got very few additions since
    then while mostly keeping compatibility with this old version which
    makes the code a bit harder to maintain. From top of my head missing
    features not support be ext/mysql include:
    * Stored Procedures (can't handle multiple result sets)
    * Prepared Statements
    * Encryption (SSL)
    so far correct
    * Compression
    not true
    client_flags and MYSQL_CLIENT_COMPRESS exists sine nearly 10 years

    this is a feature which currently sucks with mysqlnd
    because it is not supported this time
  • Ulf Wendel at Jul 15, 2011 at 1:04 pm

    Am 15.07.2011 14:56, schrieb Reindl Harald:
    client_flags and MYSQL_CLIENT_COMPRESS exists sine nearly 10 years

    this is a feature which currently sucks with mysqlnd
    because it is not supported this time
    Not true.

    Compressed Protocol Support

    As of PHP 5.3.2 MySQL Native Driver supports the compressed client
    server protocol. [...], http://www.php.net/manual/en/mysqlnd.overview.php

    Ulf
  • Johannes Schlüter at Jul 15, 2011 at 1:10 pm

    On Fri, 2011-07-15 at 14:56 +0200, Reindl Harald wrote:
    Am 15.07.2011 14:46, schrieb Johannes Schlüter:
    ext/mysql was built for MySQL 3.23 and only got very few additions since
    then while mostly keeping compatibility with this old version which
    makes the code a bit harder to maintain. From top of my head missing
    features not support be ext/mysql include:
    * Stored Procedures (can't handle multiple result sets)
    * Prepared Statements
    * Encryption (SSL)
    so far correct
    * Compression
    not true
    client_flags and MYSQL_CLIENT_COMPRESS exists sine nearly 10 years
    Thanks for the corrections.
    this is a feature which currently sucks with mysqlnd
    because it is not supported this time
    compression support was added for mysqlnd with r291051 on 2009-11-20
    09:12:14 +0100 which translates to 5.3.2, I think.

    johannes
  • Philip Olson at Jul 16, 2011 at 5:15 am
    Hola friends,

    Nice feedback so far, and the PHP documentation will begin implementing
    the ideas presented here, and focus on mysqli but also recommend pdo_mysql.
    Therefore, the ext/mysql documentation will be improved to strongly
    recommend the preferred alternatives that have existed since PHP 5.0.0.

    We'll work on the finer details but it feels like procedural mysqli is a
    better fit to live alongside the ext/mysql examples, although we don't want
    to confuse people. Maybe geeks here have ideas regarding this, but a clear
    useful clutter-free solution will be worked out, which may include adjusting
    the CSS and involve creative linking. I'll add an example or three soonish.

    However, there has been some confusion within the PHP community, so to help
    ease these concerns:

    - This proposal only deals with documentation/education... so it can be
    described as an official 'soft deprecation' (no errors or code changes)
    - When (if?) this extension emits errors, or is removed, is not part of
    this proposal
    - There is a 100% chance that additional tasks and ideas will be discussed
    in the future, which might include:
    - A conversion tool/guide
    - A wrapper
    - A PECL extension
    - Talking to distros/hosters and apps like wordpress
    - ...
    - php.net understands that ext/mysql is popular, and we're handling this
    with extra care and heck, parts of *.php.net is powered by ext/mysql
    - Seriously, no need to panic

    We'll document the reasons why the other MySQL extensions are preferred, but
    if people want to use the old ext/mysql API with PHP 9.0.0 (just an example)
    then I'm guessing an old geek out there will make that possible. We, however,
    will do our best to convince users to move towards the preferred and
    supported methods, and hopefully write better code along the way because
    honestly, that's the ultimate goal here.

    Regards,
    Philip
  • Julien Pauli at Jul 18, 2011 at 8:02 am
    I agree with Johannes and Oracle/MySQL people : ext/mysqli must be the
    preferred way to replace ext/mysql.
    PDO lacks advanced features which wont be available because of PDO
    internals incompatibility.

    ext/mysqli is a true MySQL internal API exposure into PHP user land, PDO is not.

    Moreover, ext/mysqli has a userland API that is really the same as
    ext/mysql one; it's been a design rule of ext/mysqli to ease a future
    migration.
    PDO is really different and needs objects, not every single PHP
    developper is ready to use object nowadays.

    Julien.P



    2011/7/16 Philip Olson <philip@roshambo.org>:
    Hola friends,

    Nice feedback so far, and the PHP documentation will begin implementing
    the ideas presented here, and focus on mysqli but also recommend pdo_mysql.
    Therefore, the ext/mysql documentation will be improved to strongly
    recommend the preferred alternatives that have existed since PHP 5.0.0.

    We'll work on the finer details but it feels like procedural mysqli is a
    better fit to live alongside the ext/mysql examples, although we don't want
    to confuse people. Maybe geeks here have ideas regarding this, but a clear
    useful clutter-free solution will be worked out, which may include adjusting
    the CSS and involve creative linking. I'll add an example or three soonish.

    However, there has been some confusion within the PHP community, so to help
    ease these concerns:

    - This proposal only deals with documentation/education... so it can be
    described as an official 'soft deprecation' (no errors or code changes)
    - When (if?) this extension emits errors, or is removed, is not part of
    this proposal
    - There is a 100% chance that additional tasks and ideas will be discussed
    in the future, which might include:
    - A conversion tool/guide
    - A wrapper
    - A PECL extension
    - Talking to distros/hosters and apps like wordpress
    - ...
    - php.net understands that ext/mysql is popular, and we're handling this
    with extra care and heck, parts of *.php.net is powered by ext/mysql
    - Seriously, no need to panic

    We'll document the reasons why the other MySQL extensions are preferred, but
    if people want to use the old ext/mysql API with PHP 9.0.0 (just an example)
    then I'm guessing an old geek out there will make that possible. We, however,
    will do our best to convince users to move towards the preferred and
    supported methods, and hopefully write better code along the way because
    honestly, that's the ultimate goal here.

    Regards,
    Philip


    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJul 10, '11 at 5:03p
activeJul 18, '11 at 8:02a
posts18
users13
websitephp.net

People

Translate

site design / logo © 2022 Grokbase