PDO vs pg_* functions

Question

They both have prepared statements. pg_* is a wrapper to libpq. Right?

I like the PDO in PHP, but I\'m not going to change the database in the future. Which library

Answer 1

PDO offers a nice interface but more genericity also means more trouble to deal with subtle idiosyncrasies of each backend. If you look at the bugtracker, it has a number of open issues, and some of them are serious.

Here's an anecdotal evidence with postgresql: PDO's parser has trouble with standard_conforming_strings set to ON (which is now the default, as of PG-9.1). Test case with 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"));

The execute() unexpectedly fails at the PDO layer with Database error: SQLSTATE[HY093]: Invalid parameter number: :foo. It seems that it's unable to identify :foo as a parameter.

If the query stops after 'ab\'=:foo, without another condition, then it works fine. Or if the other condition does not include a string, it works fine too.

The problem looks similar to issue #55335 , that was dismissed as Not a bug, quite wrongly in my opinion. [Actually, I've even hacked PDO myself to fix it, but in a way that is incompatible with other backends, so no patch. I was disconcerted by the query lexical analyzer being so generic.]

On the other hand, pg_* being closer to libpq, this kind of problem is less likely to happen in the first place, and easier to solve if it does.

So my point would be that not everything is nice with PDO. Internally, it's certainly more challenging than pg_*, and more complexity means more bugs. Are these bugs addressed? Based on certain bugtracker entries, not necessarily.