In this new post from Wez Furlong, he looks ar some of the things that the native MySQL client library does (the silly things) and recommends an alternative with the PDO libraries.

I've recently discovered a few things about how the mysql client library does things that seem a bit silly to me, so I'm going to share them with you.

Among the things he mentions functionality (dealing with prepared statements) like "native prepared statements cannot take advantage of the query cache" and "native prepared statements cannot execute certain types of queries". The gives a simple line of code to make the database functionality (in PHP 5.1.3 and later) use the native PDO query parser to be loaded versus the one for the standard MySQL client libraries.

Ilia Alshanetsky also has hos own look today at the "mysql_real_escape_string versus addslashes" debate that's going on, looking more at why there's even an issue here (with addslashes).

Chris has written a compelling piece about how the use of addslashes() for string escaping in MySQL queries can lead to SQL injection through the abuse of multibyte character sets. In his example he relies on addslashes() to convert an invalid multibyte sequence into a valid one, which also has an embedded ' that is not escaped. And in an ironic twist, the function intended to protect against SQL injection is used to actually trigger it.

The problem demonstrated, actually goes a bit further, which even makes the prescribed escaping mechanism, mysql_real_escape_string() prone to the same kind of issues affecting addslashes().

He shows code examples, creating a simple SQL injection that uses mysql_real_escape_string to cause the same issue - all based around the default characterset that the MySQL server uses. His suggested solution? Prepared statements... (like what things such as PDO offer)