PDO biedt een mooie interface, maar meer genericiteit betekent ook meer moeite om met subtiele eigenaardigheden van elke backend om te gaan. Als je naar de bugtracker kijkt, zijn er een aantal openstaande problemen, en sommige zijn serieus.
Hier is een anekdotisch bewijs met postgresql:PDO's parser heeft problemen met standard_conforming_strings ingesteld op ON (wat nu de standaard is, vanaf PG-9.1). Testcase met 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"));
De execute() mislukt onverwacht op de PDO-laag metDatabase error: SQLSTATE[HY093]: Invalid parameter number: :foo . Het lijkt erop dat het :foo niet kan identificeren als een parameter.
Als de zoekopdracht stopt na 'ab\'=:foo , zonder een andere voorwaarde, dan werkt het prima. Of als de andere voorwaarde geen string bevat, werkt het ook prima.
Het probleem lijkt op probleem #55335 , dat werd afgewezen als Geen bug , helemaal ten onrechte naar mijn mening. [Eigenlijk heb ik PDO zelf gehackt om het te repareren, maar op een manier die niet compatibel is met andere backends, dus geen patch. Ik was verontrust door het feit dat de lexicale analyser voor zoekopdrachten zo algemeen was.]
Aan de andere kant, omdat pg_* dichter bij libpq ligt, is de kans kleiner dat dit soort problemen zich voordoen, en gemakkelijker op te lossen als dat zo is.
Dus mijn punt zou zijn dat niet alles leuk is met PDO. Intern is het zeker uitdagender dan pg_*, en meer complexiteit betekent meer bugs. Worden deze bugs aangepakt? Gebaseerd op bepaalde bugtracker-vermeldingen, niet noodzakelijk.