I don't know if this is technically doable, but having PDOStatement as bound value would be great. Imagine two PDOStatements:

$sql1 = 'SELECT * FROM resources WHERE id IN :access';
$s1 = $pdo->prepare($sql1);

$sql2 = 'SELECT resource_id FROM access WHERE user_id = :uid'
$s2 = $pdo->prepare($sql2);

$s2->bindValue('uid', 1);
$s1->bindValue('access', $s2);

I often use delegate objects that provide partial SQL to be included depending on filter state. This would make pluggable subselects much cleaner.

I'd like to see a mechanism for specifying the character set, so that you don't have to manually query the database using "SET CHARACTER SET utf8" anymore.

The bug I have found in PDO that causes grief is that it fails if a quoted string contains both a parameter placeholder and an escaped quote.

SELECT * FROM tabl WHERE string = '?\'foo'
SELECT * FROM tabl WHERE string = ':param\'foo'

Normally placeholders inside strings are ignored. Even though the placeholders are inside a string literal, somehow it is reported to the RDBMS that these are parameters and we get errors if we don't supply parameter values during execution.

This does not affect non-PDO interfaces such as mysqli. It's not clear if this affects all PDO drivers or only certain PDO drivers.

The suggestions about binding lists of values or whole statements are non-starters.

SQL query parameters can be used only as a placeholder for a single scalar value.

That's just part of the way the SQL language works.

You can't parameterize extra SQL syntax. A comma-separated list of values counts as extra SQL syntax.

Additional work on stability is required.
Support of multiple resultsets for mssql and odbc on all platforms.
Fix the problems with ODBC prepared statements when executing procedures on all platforms.

Basically, you should make it universal database access tool as it is intended to be, not just yet another mysql driver, as I see it now. You should make it work on all platforms, everywhere, always, before you start adding yet another set of features that probably only work for mysql anyway.

I've been implementing a PDO-based database layer for Drupal recently, so these comments come from my experience in doing so:

1) http://bugs.php.net/bug.php?id=44135 - This is a highly irritating bug, as it makes the degenerate case of a merge query much more difficult to implement. It requires trying to insert, failing, catching an exception, checking the insert statement's error code, and potentially running an update. It would be much simpler to run an update, and if no rows *match* (instead of no rows *change*), run an insert. (No database supports single-statement merge queries in the same way.)

2) As others have mentioned, the ability to use BLOB and CLOB fields consistently across databases. On MySQL, SQLite, and a few others, all fields can be passed in via ->execute(). On PostgreSQL, BLOB fields require using a ->bind() on every field in the query, which requires knowing in advance what the type is of every field. On Oracle and DB2 (at least), you have to do that for BLOB or CLOB fields; that is, pretty much any text of interesting length. While for super-large values it makes sense to stream the data in from a file, for 99% of cases it just makes life harder and makes queries harder to generalize. So the feature request here is to allow type-agnostic placeholder handling consistently across all databases.

3) While I understand that with prepared statements the query does not, in fact, get string-replaced into a complete query and executed but is compiled first and then executed with parameters, that still makes debugging from a query log much harder than it should be. A "simulated query string" function for debugging (e.g., PDOStatement->pseudoQuery() which returns a string?) would be very useful.

Item 2, I think, is my #1 pain in the ass right now with PDO. Even if I standardize my SQL strings, I cannot actually write database-portable code in any sane fashion because of widely different field handling. I am fine with doing my own array/WHERE IN handling and the like, but having to care about field types *only sometimes* makes database portability 10x as hard as it should be.

What I'm missing in current PDO is that there is too less parameter data types. At least two is coming to my mind I have missed and have to workaround lately. Float (Decimal) and Date/DateTime.

Thanks for all the feedback. Not all items will be easily doable. Also as noted adding support for "IN (?)" style placeholders is not really doable. However something like MDB2's implodeArray() is. Also MDB2 features very cheap subquery emulation via the subSelect() method.

In the spirit of the requested Float/Date datatype improvements, one other topic that might be of interest could be beefing up the PHP integer datatype to 64bit.

Reusing the same placeholder multiple times seems to work for me:

<?php
$dsn = 'sqlite::memory:';

try {
    $dbh = new PDO($dsn);
} catch (PDOException $e) {
    echo 'Connection failed: ' . $e->getMessage();
}

$sql = 'CREATE TABLE fruit (name VARCHAR(100), calories INT, colour VARCHAR(100))';
$sth = $dbh->exec($sql);

$sql = "INSERT INTO fruit (name, calories, colour) VALUES ('apple', 55, 'green')";
$sth = $dbh->exec($sql);

$sql = 'SELECT name, colour, calories
    FROM fruit';
$sth = $dbh->prepare($sql);
$sth->execute();
$all = $sth->fetchAll(PDO::FETCH_ASSOC);
var_dump($all);

$sql = 'SELECT name, colour, calories
    FROM fruit
    WHERE calories < :colour AND colour = :colour';
$sth = $dbh->prepare($sql, array(PDO::ATTR_CURSOR => PDO::CURSOR_FWDONLY));
$sth->execute(array('colour' => 'green'));
$all = $sth->fetchAll(PDO::FETCH_ASSOC);
var_dump($all);
?>

Well, my top two request are allready mentioned. There are both relatively easy to emulate in user space code (and we do) but having them in PDO would make PDO more valuable to us (and our code nicer).

So support for an easy IN handling, which we use a lot, would be cool and save us some code. The "simulated query string" which Larry Garfield mentioned would also save us some pain. We currently have some logging function which emulates this in a very basic way. But a function in PDO would also make this less painfull and more reliable for us.

Bye the way, thanks for asking!