PDO tilbyder en god grænseflade, men mere genericitet betyder også mere besvær med at håndtere subtile idiosynkrasier i hver backend. Hvis du ser på bugtrackeren, har den en række åbne problemer, og nogle af dem er alvorlige.
Her er et anekdotisk bevis med postgresql:PDO's parser har problemer med standard_conforming_strings sat til ON (som nu er standard fra PG-9.1). Testcase med 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"));
execute() fejler uventet på PDO-laget medDatabase error: SQLSTATE[HY093]: Invalid parameter number: :foo . Det ser ud til, at det ikke er i stand til at identificere :foo som en parameter.
Hvis forespørgslen stopper efter 'ab\'=:foo , uden en anden betingelse, så fungerer den fint. Eller hvis den anden betingelse ikke indeholder en streng, fungerer den også fint.
Problemet ligner problemstilling #55335 , der blev afvist som Ikke en fejl , helt forkert efter min mening.[Faktisk har jeg endda selv hacket PDO for at rette det, men på en måde, der er uforenelig med andre backends, så ingen patch. Jeg var forvirret over, at forespørgselsleksikalsk analysator var så generisk.]
På den anden side, da pg_* er tættere på libpq, er det mindre sandsynligt, at denne type problem opstår i første omgang, og lettere at løse, hvis det sker.
Så min pointe ville være, at ikke alt er rart med PDO. Internt er det bestemt mere udfordrende end pg_*, og mere kompleksitet betyder flere fejl. Er disse fejl rettet? Baseret på visse bugtracker-indgange, ikke nødvendigvis.