PDO bietet eine schöne Schnittstelle, aber mehr Allgemeinheit bedeutet auch mehr Mühe, mit subtilen Eigenheiten jedes Backends umzugehen. Wenn Sie sich den Bugtracker ansehen, gibt es eine Reihe offener Probleme, und einige davon sind schwerwiegend.
Hier ist ein anekdotischer Beweis mit postgresql:Der Parser von PDO hat Probleme mit standard_conforming_strings, die auf ON gesetzt sind (was jetzt die Standardeinstellung ist, seit PG-9.1). Testfall mit 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"));
Das execute() schlägt unerwartet auf der PDO-Schicht fehl mit Database error: SQLSTATE[HY093]: Invalid parameter number: :foo . Es scheint, dass es :foo nicht als Parameter identifizieren kann.
Wenn die Abfrage nach 'ab\'=:foo stoppt , ohne eine weitere Bedingung, dann funktioniert es gut. Oder wenn die andere Bedingung keinen String enthält, funktioniert es auch gut.
Das Problem ähnelt Problem Nr. 55335 , das als Kein Fehler abgetan wurde , meiner Meinung nach ziemlich zu Unrecht.[Eigentlich habe ich PDO sogar selbst gehackt, um es zu beheben, aber auf eine Weise, die mit anderen Backends nicht kompatibel ist, also kein Patch. Ich war beunruhigt darüber, dass der lexikalische Analysator für Abfragen so generisch ist.]
Da andererseits pg_* näher an libpq liegt, ist es weniger wahrscheinlich, dass diese Art von Problem überhaupt auftritt, und leichter zu lösen, wenn dies der Fall ist.
Mein Punkt wäre also, dass bei PDO nicht alles schön ist. Intern ist es sicherlich anspruchsvoller als pg_*, und mehr Komplexität bedeutet mehr Fehler. Werden diese Fehler behoben? Basierend auf bestimmten Bugtracker-Einträgen nicht unbedingt.
