Menu
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 should I use? Any benchmark? PHP version: 5.4
523
PDO provides a data-access abstraction layer, which means that, regardless of which database you're using, you use the same functions to issue queries and fetch data. PDO does not provide a database abstraction; it doesn't rewrite SQL or emulate missing features.
The PDO_PGSQL is a driver that implements the PDO interface. It allows you to access PostgreSQL databases from PHP. To check if the PDO_PGSQL driver is enabled, you open the php. ini file.
PDO::query() returns a PDOStatement object, or FALSE on failure.
PDO is an acronym for PHP Data Objects. PDO is a lean, consistent way to access databases. This means developers can write portable code much easier. PDO is not an abstraction layer like PearDB. PDO is a more like a data access layer which uses a unified API (Application Programming Interface).
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.
90
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
