# [patch] mysql_warning_count() for ext/mysql - Thread: https://externals.io/message/45742 - Original archive: https://news-web.php.net/php.internals/45742 - Started by Jille Timmermans on 2009-10-12T15:03:20+00:00 - Messages: 7 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #45742 — Jille Timmermans — 2009-10-12T15:03:20+00:00 URL: https://externals.io/message/45742#45742 Hello all, Not sure whether this is the right place to post; but it seemed a little bit better than php-db@. I have 'implemented' MySQL's mysql_warning_count() function. ( http://dev.mysql.com/doc/refman/5.1/en/mysql-warning-count.html ) mysql_warning_count() is available in MySQL's C-api in >3.23, >4.1 and >5 This function returns the number of warnings from the previous query. In some queries (INSERT INTO .. VALUES (..), (..); INSERT INTO .. SELECT; etc) mysql_info() was usable to return the number of warnings; but for single-row inserts mysql_info() returns false. The function is very straightforward, almost the same as mysql_thread_id(). The patch is available at http://jille.hexon.cx/mysql-warning-count.diff It is based on PHP 5.3.0 and at least works for me. -- Jille --- ## #45743 — Ulf Wendel — 2009-10-12T15:32:06+00:00 URL: https://externals.io/message/45742#45743 · In reply to: #45742 Jille Timmermans schrieb: > I have 'implemented' MySQL's mysql_warning_count() function. ( > http://dev.mysql.com/doc/refman/5.1/en/mysql-warning-count.html ) > mysql_warning_count() is available in MySQL's C-api in >3.23, >4.1 and >5 I am not a big fan of adding anything to ext/mysql that is not security relevant or mission critical. mysql_warning_count() is a convenience function. Let ext/mysql run out and use ext/mysqli instead. ext/mysqli is around since PHP 5.0 = 2004 = 5 years. It can be considered as faily stable. It is as easy to use as ext/mysql. Performance is virtually identical. Only ext/mysqli gives you access to all functionality of MySQL 4.1 and above, e.g. charset and prepared statements. I see no reasons for updating ext/mysql when there is a successor (for so long). Ulf -- Ulf Wendel, MySQL Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028 --- ## #45801 — Jille Timmermans — 2009-10-13T12:10:05+00:00 URL: https://externals.io/message/45742#45801 · In reply to: #45743 Ulf Wendel schreef: > Jille Timmermans schrieb: > > […] > > I am not a big fan of adding anything to ext/mysql that is not security > relevant or mission critical. mysql_warning_count() is a convenience > function. It is performance 'critical': Without this function I will have to query 'SHOW WARNINGS' after every query, which won't be good for the performance. > > Let ext/mysql run out and use ext/mysqli instead. ext/mysqli is around > since PHP 5.0 = 2004 = 5 years. It can be considered as faily stable. It > is as easy to use as ext/mysql. Performance is virtually identical. ext/mysqli didn't have persistent connections till 5.3; this made it impossible for me to switch to it at the time we had to decide. > > Only ext/mysqli gives you access to all functionality of MySQL 4.1 and > above, e.g. charset and prepared statements. Why would you hide functionality from people when you get a patch, and all that has to be done is commit it? I'm pretty sure it won't break anything. > > I see no reasons for updating ext/mysql when there is a successor (for > so long). It should have been included a long time ago, IMHO. -- Jille > > Ulf --- ## #45802 — Ulf Wendel — 2009-10-13T13:15:16+00:00 URL: https://externals.io/message/45742#45802 · In reply to: #45801 Jille Timmermans schrieb: > > […] > Why would you hide functionality from people when you get a patch, and > all that has to be done is commit it? I'm pretty sure it won't break > anything. ext/mysql already "hides" functionality, for example, prepared statements. If you add all the missing pieces to ext/mysql you get ext/mysqli... Ulf -- Ulf Wendel, MySQL Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028 --- ## #45803 — Alexey Zakhlestin — 2009-10-13T13:16:27+00:00 URL: https://externals.io/message/45742#45803 · In reply to: #45801 > Why would you hide functionality from people when you get a patch, > and all that has to be done is commit it? I'm pretty sure it won't > break anything. Definitely +1 from me. As long as ext/mysql is bundled with php (which means "officially supported") I see no reason to reject simple patches --- ## #45804 — Ulf Wendel — 2009-10-13T13:26:08+00:00 URL: https://externals.io/message/45742#45804 · In reply to: #45803 Alexey Zakhlestin schrieb: > > > > > […] > > Definitely +1 from me. > As long as ext/mysql is bundled with php (which means "officially > supported") I see no reason to reject simple patches Definetly -1 from my side: what maked warning count different from prepared statements? If ext/mysql would not have such a tremendous user base, I would even suggest to disable it by default. Ulf -- Ulf Wendel, MySQL Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028 --- ## #45805 — Alexey Zakhlestin — 2009-10-13T13:53:52+00:00 URL: https://externals.io/message/45742#45805 · In reply to: #45804 > Alexey Zakhlestin schrieb: > > […] > > Definetly -1 from my side: what maked warning count different from > prepared statements? lack of patch > If ext/mysql would not have such a tremendous user base, I would > even suggest to disable it by default. there was a chance to mark it "deprecated" in 5.3