PDO erbjuder ett trevligt gränssnitt men mer genericitet innebär också mer problem att hantera subtila egenheter i varje backend. Om du tittar på bugtrackern har den ett antal öppna problem, och några av dem är allvarliga.
Här är ett anekdotiskt bevis med postgresql:PDO:s parser har problem med standard_conforming_strings satt till ON (vilket nu är standard, från och med PG-9.1). Testfall 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() misslyckas oväntat i PDO-lagret medDatabase error: SQLSTATE[HY093]: Invalid parameter number: :foo . Det verkar som om det inte går att identifiera :foo som en parameter.
Om frågan slutar efter 'ab\'=:foo , utan ett annat villkor, då fungerar det bra. Eller om det andra villkoret inte innehåller en sträng, fungerar det också bra.
Problemet liknar problem #55335 , som avfärdades som Inte ett fel , helt felaktigt enligt min mening.[Faktiskt har jag till och med hackat PDO själv för att fixa det, men på ett sätt som är inkompatibelt med andra backends, så ingen patch. Jag blev förvånad över att frågans lexikalanalys var så generisk.]
Å andra sidan, eftersom pg_* är närmare libpq, är det mindre sannolikt att den här typen av problem inträffar i första hand och lättare att lösa om det gör det.
Så min poäng skulle vara att allt inte är bra med PDO. Internt är det säkert mer utmanande än pg_*, och mer komplexitet innebär fler buggar. Är dessa buggar åtgärdade? Baserat på vissa bugtracker-poster, inte nödvändigtvis.