PDO ofrece una interfaz agradable, pero más genericidad también significa más problemas para lidiar con las sutiles idiosincrasias de cada backend. Si observa el rastreador de errores, tiene una serie de problemas abiertos y algunos de ellos son graves.
Aquí hay una evidencia anecdótica con postgresql:el analizador de PDO tiene problemas con las cadenas de conformidad estándar establecidas en ON (que ahora es el valor predeterminado, a partir de PG-9.1). Caso de prueba con 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"));
La ejecución () falla inesperadamente en la capa PDO con Database error: SQLSTATE[HY093]: Invalid parameter number: :foo . Parece que no puede identificar :foo como parámetro.
Si la consulta se detiene después de 'ab\'=:foo , sin otra condición, entonces funciona bien. O si la otra condición no incluye una cadena, también funciona bien.
El problema se parece al número 55335, que se descartó como No es un error , bastante mal en mi opinión. [En realidad, incluso pirateé PDO para solucionarlo, pero de una manera que es incompatible con otros backends, por lo que no hay parche. Me desconcertó que el analizador léxico de consultas fuera tan genérico.]
Por otro lado, al estar pg_* más cerca de libpq, es menos probable que ocurra este tipo de problema en primer lugar, y más fácil de resolver si ocurre.
Entonces, mi punto sería que no todo es bueno con PDO. Internamente, es ciertamente más desafiante que pg_*, y más complejidad significa más errores. ¿Se solucionan estos errores? Basado en ciertas entradas de bugtracker, no necesariamente.
