他们俩都有准备好的陈述。
pg_ *是libpq的包装器。正确的？
我喜欢PHP中的PDO，但以后不会更改数据库。
我应该使用哪个库？
有基准吗？
PHP版本:5.4
最佳答案
PDO提供了一个不错的接口(interface)，但是更多的通用性也意味着在处理每个后端的微妙特性时会遇到更多的麻烦。如果您查看the bugtracker，它有很多 Unresolved 问题，其中有些是很严重的。
这是有关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之后停止，而没有其他条件，则可以正常工作。或者，如果其他条件不包含字符串，它也可以正常工作。
该问题看起来与issue #55335相似，在我看来，该错误被视为不是错误而被驳回。
[实际上，我什至亲自破解了PDO来修复它，但是这种方式与其他后端不兼容，因此没有补丁。查询词法分析器是如此通用，令我感到不安。]
另一方面，由于pg_ *更接近libpq，这种问题在一开始就不太可能发生，如果确实发生，则更容易解决。
因此，我的观点是，PDO并非一切都很好。在内部，它肯定比pg_ *更具挑战性，并且更高的复杂性意味着更多的错误。这些错误已解决吗？基于某些bugtracker条目，不一定。
关于php - PDO与pg_ *功能，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/10384224/