PDO oferuje ładny interfejs, ale większa generacja oznacza również więcej kłopotów z radzeniem sobie z subtelnymi idiosynkrazjami każdego zaplecza. Jeśli spojrzysz na bugtracker, ma on wiele otwartych problemów, a niektóre z nich są poważne.
Oto anegdotyczny dowód dotyczący postgresql:parser PDO ma problem z ustawieniem standard_conforming_strings na ON (co jest teraz domyślnym ustawieniem od PG-9.1). Przypadek testowy z 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"));
Funkcja execute() nieoczekiwanie kończy się niepowodzeniem w warstwie PDO z Database error: SQLSTATE[HY093]: Invalid parameter number: :foo . Wygląda na to, że nie jest w stanie zidentyfikować :foo jako parametru.
Jeśli zapytanie zatrzyma się po 'ab\'=:foo , bez innego warunku, to działa dobrze. Lub jeśli drugi warunek nie zawiera ciągu, również działa dobrze.
Problem wygląda podobnie do problemu nr 55335 , który został odrzucony jako Nie jest to błąd , moim zdaniem całkiem niesłusznie. [Właściwie sam zhakowałem PDO, żeby to naprawić, ale w sposób, który jest niekompatybilny z innymi backendami, więc nie ma łatki. Byłem zaniepokojony tym, że analizator leksykalny zapytań jest tak ogólny.]
Z drugiej strony, pg_* jest bliżej libpq, ten rodzaj problemu jest mniej prawdopodobny i łatwiejszy do rozwiązania, jeśli tak się stanie.
Chodzi mi więc o to, że nie wszystko jest w porządku z PDO. Wewnętrznie jest to z pewnością trudniejsze niż pg_*, a większa złożoność oznacza więcej błędów. Czy te błędy zostały rozwiązane? Niekoniecznie na podstawie pewnych wpisów bugtrackera.
