PDO offre una bella interfaccia, ma più genericità significa anche più problemi a gestire le sottili idiosincrasie di ciascun back-end. Se guardi il bugtracker, ha una serie di problemi aperti e alcuni di essi sono seri.
Ecco una prova aneddotica con postgresql:il parser di PDO ha problemi con standard_conforming_strings impostato su ON (che ora è l'impostazione predefinita, a partire da PG-9.1). Caso di test 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"));
L'esecuzione() fallisce inaspettatamente al livello PDO con Database error: SQLSTATE[HY093]: Invalid parameter number: :foo . Sembra che non sia in grado di identificare :foo come parametro.
Se la query si interrompe dopo 'ab\'=:foo , senza un'altra condizione, funziona correttamente. Oppure, se l'altra condizione non include una stringa, funziona ugualmente.
Il problema è simile al problema #55335 , che è stato respinto come Non è un bug , secondo me abbastanza erroneamente.[In realtà, ho persino hackerato PDO da solo per risolverlo, ma in un modo incompatibile con altri backend, quindi nessuna patch. Sono rimasto sconcertato dal fatto che l'analizzatore lessicale delle query fosse così generico.]
D'altra parte, essendo pg_* più vicino a libpq, è meno probabile che questo tipo di problema si verifichi in primo luogo e, in tal caso, è più facile risolverlo.
Quindi il mio punto sarebbe che non tutto va bene con PDO. Internamente, è sicuramente più impegnativo di pg_* e più complessità significa più bug. Questi bug sono stati risolti? Basato su alcune voci di bugtracker, non necessariamente.
