PDO offre une interface agréable mais plus de généricité signifie également plus de difficulté à gérer les particularités subtiles de chaque backend. Si vous regardez le bugtracker, il y a un certain nombre de problèmes ouverts, et certains d'entre eux sont sérieux.
Voici une preuve anecdotique avec postgresql :l'analyseur de PDO a des problèmes avec standard_conforming_strings défini sur ON (qui est maintenant la valeur par défaut, à partir de PG-9.1). Cas de test avec php-5.3.9 :
$dbh->exec("SET standard_conforming_strings=on");
$p=$dbh->prepare("SELECT 1 WHERE 'ab\' = :foo AND 'cd' = :bar");
$p->execute(array(":foo" => "ab", ":bar" => "cd"));
L'execute() échoue de manière inattendue au niveau de la couche PDO avec Database error: SQLSTATE[HY093]: Invalid parameter number: :foo . Il semble qu'il soit incapable d'identifier :foo en tant que paramètre.
Si la requête s'arrête après 'ab\'=:foo , sans autre condition, alors ça marche bien. Ou si l'autre condition n'inclut pas de chaîne, ça marche bien aussi.
Le problème ressemble au problème #55335 , qui a été rejeté comme Pas un bogue , assez à tort à mon avis. [En fait, j'ai même hacké PDO moi-même pour le réparer, mais d'une manière incompatible avec d'autres backends, donc pas de patch. J'ai été déconcerté par la généralité de l'analyseur lexical des requêtes.]
D'autre part, pg_* étant plus proche de libpq, ce type de problème est moins susceptible de se produire en premier lieu, et plus facile à résoudre si c'est le cas.
Donc mon point serait que tout n'est pas bien avec PDO. En interne, c'est certainement plus difficile que pg_*, et plus de complexité signifie plus de bogues. Ces bugs sont-ils corrigés ? Basé sur certaines entrées de bugtracker, pas nécessairement.
