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
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
Ulf Wendel schreef:
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 >5I 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
Jille Timmermans schrieb:
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.
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
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
Alexey Zakhlestin 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.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
Alexey Zakhlestin 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.
Definitely +1 from me.
As long as ext/mysql is bundled with php (which means "officially
supported") I see no reason to reject simple patchesDefinetly -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