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, този вид проблем е по-малко вероятно да се случи на първо място и по-лесно се решава, ако се случи.
Така че моята гледна точка би била, че не всичко е хубаво със ЗНП. Вътрешно това със сигурност е по-предизвикателно от pg_*, а по-голямата сложност означава повече грешки. Отстранени ли са тези грешки? Въз основа на определени записи в програмата за проследяване на грешки, не е задължително.
