[patch] mysql_warning_count() for ext/mysql

15 years ago by Jille Timmermans — view source

unread

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

15 years ago by Ulf Wendel — view source

unread

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

15 years ago by Jille Timmermans — view source

unread

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

15 years ago by Ulf Wendel — view source

unread

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

15 years ago by Alexey Zakhlestin — view source

unread

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

15 years ago by Ulf Wendel — view source

unread

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

15 years ago by Alexey Zakhlestin — view source

unread

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?

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