Reinis Rozitis <r...@roze.lv> wrote:
>> Rewriting perfectly functional mysql code to use mysqli is not a >trivial >> move, just as are the problems of re-writing PHP5.2 code to work >cleanly >> on 5.4. ISP's are stuck between keeping customers - who are most >likely >> not even very computer literate - working while fighting the problems >that >> changes such as removing mysql will cause them. > > >I wonder if there have been any plans or suggestions (while dropping >the >old ext/mysql code) to provide some sort of seamless >migration/alternatives >(similar way it has been done in case of libmysql and mysqlnd)? >In short - just aliasing the old mysql_* to mysqli_* functions (as most >used >like _query, _fetch_row/assoc have just mixed variable order)? > Reimplementing ext/mysql inside PHP makes no sense. The result of this would be (almost) the exact same code as we have. (ext/mysql is a exremely small wrapper over libmysql/mysqlnd only special thngs are pconnect, auto connect and reusage of default connection) What one might try to do is changing ext/mysql to not use a resource but an mysqli object, then users might swich module by module, instead of breaking the application completely. But I fear we will introduce many bugs that way as this is a quite huge patch. An alternative approach might be to reimplement mysql_* functions using PHP userland code based on mysqli. Then users can load that lib (php.ini autoprepend_file) for compatibility and bugs can be fixed relatively simple (no C needed, no PHP release needed, ...) but again: writing such a lib is a relatively huge project. In my opinion we tell users as good as we can that ext/mysql is deprecated for some time, if we really want to get rid of it, we have to add E_DEPRECATED and then remove it.Waiting a year more won't change much, there will always people who hit it. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
