Hi, Monty,

I recently had a discussion with some DBD::mysql users, in particular Tim Bunce the DBI maintainer, about the following:

If I do a

UPDATE foo SET col=col

then the MySQL optimizer detects that no work needs to be done, which is of course a good thing. The problem is that mysql_affected_rows seems to return the value 0, in other words the number of *physically* affected rows. This seems to break some peoples reliabiliy checks, which expects the number of rows being returned.

On the other hand the MySQL server obviously knows the number of matched rows:

mysql> update user set Host=Host; Query OK, 0 rows affected (0.00 sec) Rows matched: 11 Changed: 0 Warnings: 0

It seems this information is now returned by mysql_info(). (I didn't verify.)

I am now asked to change the DBD::mysql driver not to return the result of mysql_affected_rows(), but read mysql_info() and parse the output to return the matched rows. This is something I definitely don't like, because it is slow and unsafe.

My question is whether you can either

- supply the same info via a new function, mysql_matched_rows(), say or - change mysql_affected_rows to return the number of matched rows

Thanks,

Jochen