O PDO oferece uma interface agradável, mas mais genericidade também significa mais problemas para lidar com idiossincrasias sutis de cada backend. Se você olhar para o bugtracker, ele tem vários problemas em aberto, e alguns deles são sérios.
Aqui está uma evidência anedótica com o postgresql:O analisador do PDO tem problemas com standard_conforming_strings definido como ON (que agora é o padrão, a partir do PG-9.1). Caso de teste com 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"));
O execute() falha inesperadamente na camada PDO com
Database error: SQLSTATE[HY093]: Invalid parameter number: :foo . Parece que não consegue identificar :foo como parâmetro. Se a consulta parar após
'ab\'=:foo , sem outra condição, funcionará bem. Ou se a outra condição não incluir uma string, funcionará bem também. O problema é semelhante ao número 55335 , que foi descartado como Não é um bug , erroneamente na minha opinião.[Na verdade, eu mesmo hackeei o PDO para consertá-lo, mas de uma forma que é incompatível com outros backends, então sem patch. Fiquei desconcertado com o analisador léxico de consulta sendo tão genérico.]
Por outro lado, sendo pg_* mais próximo de libpq, esse tipo de problema é menos provável de acontecer em primeiro lugar, e mais fácil de resolver se acontecer.
Então, meu ponto seria que nem tudo é bom com PDO. Internamente, é certamente mais desafiador do que pg_*, e mais complexidade significa mais bugs. Esses bugs são corrigidos? Com base em certas entradas do rastreador de bugs, não necessariamente.
