पीडीओ बनाम पीजी_* कार्य

पीडीओ एक अच्छा इंटरफ़ेस प्रदान करता है लेकिन अधिक सामान्यता का अर्थ प्रत्येक बैकएंड की सूक्ष्म विशिष्टताओं से निपटने के लिए अधिक परेशानी भी है। यदि आप बगट्रैकर को देखें, तो इसमें कई खुले मुद्दे हैं, और उनमें से कुछ गंभीर हैं।

यहाँ 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"));

PDO परत पर निष्पादित () अनपेक्षित रूप से विफल हो जाता है Database error: SQLSTATE[HY093]: Invalid parameter number: :foo . ऐसा लगता है कि यह :foo को एक पैरामीटर के रूप में पहचानने में असमर्थ है।

अगर क्वेरी 'ab\'=:foo . के बाद बंद हो जाती है , किसी अन्य शर्त के बिना, यह ठीक काम करता है। या यदि अन्य शर्त में एक स्ट्रिंग शामिल नहीं है, तो यह भी ठीक काम करता है।

समस्या #55335 अंक के समान दिखती है, जिसे कोई बग नहीं . के रूप में खारिज कर दिया गया था , मेरी राय में काफी गलत है। [दरअसल, मैंने इसे ठीक करने के लिए खुद पीडीओ को हैक कर लिया है, लेकिन एक तरह से जो अन्य बैकएंड के साथ असंगत है, इसलिए कोई पैच नहीं। मैं क्वेरी लेक्सिकल एनालाइज़र के इतने सामान्य होने से निराश था।]

दूसरी ओर, pg_* libpq के करीब होने के कारण, इस तरह की समस्या पहली बार में होने की संभावना कम होती है, और अगर ऐसा होता है तो इसे हल करना आसान होता है।

तो मेरा कहना यह होगा कि पीडीओ के साथ सब कुछ अच्छा नहीं है। आंतरिक रूप से, यह निश्चित रूप से pg_* से अधिक चुनौतीपूर्ण है, और अधिक जटिलता का अर्थ है अधिक बग। क्या इन बगों को संबोधित किया गया है? कुछ बगट्रैकर प्रविष्टियों के आधार पर, जरूरी नहीं।