PDOは優れたインターフェイスを提供しますが、汎用性が高いほど、各バックエンドの微妙な特異性に対処するための問題も多くなります。バグトラッカーを見ると、未解決の問題がいくつかあり、そのうちのいくつかは深刻です。
postgresqlの事例証拠は次のとおりです。PDOのパーサーは、standard_conforming_stringsがONに設定されていると問題が発生します（PG-9.1ではデフォルトになっています）。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（）がPDOレイヤーで予期せず失敗し、Database error: SQLSTATE[HY093]: Invalid parameter number: :foo 。 ：fooをパラメータとして識別できないようです。
'ab\'=:fooの後にクエリが停止した場合 、別の条件がない場合は正常に機能します。または、他の条件に文字列が含まれていない場合も正常に機能します。
問題は問題＃55335に似ており、バグではないとして却下されました。 、私の意見ではまったく間違っています。[実際、私はPDOを自分でハッキングして修正しましたが、他のバックエンドと互換性がないため、パッチはありません。クエリ字句解析プログラムが非常に一般的であることに戸惑いました。]
一方、pg_ *はlibpqに近いため、この種の問題はそもそも発生する可能性が低く、発生した場合は解決しやすくなります。
ですから、私のポイントは、PDOですべてがうまくいくわけではないということです。内部的には、それは確かにpg_ *よりも困難であり、複雑さが増すとバグが増えることを意味します。これらのバグは解決されていますか？特定のバグトラッカーエントリに基づいていますが、必ずしもそうとは限りません。