In Drupal 6 and below a sql injection vulnerability/attack was limited in what it could achieve by the surrounding statement. For example, if there were a select statement it could only do selects and maybe union data, but it couldn't be closed with a ; and then have an update executed. An update of one table could only update that one table.
Drupal 7, with adopting PDO, makes it possible to close off the first query and execute a second query. This makes a sql injection vulnerability a much riskier thing.
### Risks/benefits:
* Benefit: not executing multiple queries.
* Risk/Benefit (?): statement preparation (including security related elements) is moved to mysql instead of php. I don't know how that might impact any code we have related to security. It seems reasonable to me to trust the mysql escaping as much as the PHPPDO escaping.
* Risk: validation of statements, including exceptions about a column or table that is missing, will be thrown during prepare instead of execute. We may have some code that relies on
* Risk: query cache won't be used on mysql less than 5.1.
### Some research:
* the original thread that pointed me to this option
* A pretty solid stack overflow thread on php-pdo-mysql and impact
* php documentation on the attribute - pretty limited
I'm purposefully filing this in public. Even though it is related to security it's about hardening. This issue doesn't expose any vulnerabilities in Drupal and a change like this deserves broad review.