PDO Drivers

Hi Narf,

Isn't that the point of PDO though?

Why does CI support PDO drivers when it doesn't actually use the PDO methods? It would seem rather misleading?!

As pointed out by others already, the point of PDO is abstraction. CodeIgniter has its own abstraction; the reason why we have PDO drivers is rather silly - PDO is preached as the de-facto standard way for database access in PHP, and so people want to use it and complain if you don't have it.
Although, there are small side benefits like it supporting obscure databases like Informix, which have no other alternative driver.

However, the reason why you seem rather irritated by this is a common fallacy ...

The reason why PDO usage is preached is not a bad one - it offers an easy way to use and enforeprepared statements, which happen to be an effective way of eliminating SQL injections. SQLi was a huge problem in the PHP eco-system (actually, it is still the #1 security issue, but great progress has been made) and so it is completely natural that you've been taught to always use prepare(), execute() - that's how you do prepared statements.

But that does not in any way mean that these 2 methods are all there is to PDO, nor are they the point of it. In fact, platform-specific drivers are way more powerful, and likely less buggy (as they get more support directly from DB vendors, while PDO's internal code is a mess).
mysqli, pgsql, oci8 in particular offer features way more advanced than what's even possible in PDOIt's just that platform-specific extension. The problem with them though, and why PDO is recommended for the average user, is that they also have pretty ugly and hard to use APIs. With them, it is hard to use them correctly and easy to make mistakes - something that every security professional will tell you is a horrible, horrible thing. If there's a way to misuse an API, people will do exactly that!

And here comes the silly part - prepare() and execute() don't actually guarantee that you're using prepared statements! There's a flag named PDO::ATTR_EMULATE_PREPARES, which causes such statements to be emulated, or in other words - simply escape strings in the background. I can't find info about it now, but a few years ago it was known that it defaults to TRUE for MySQL (FALSE for SQLSRV according to Microsoft docs, but who cares about that /jk; dunno about other drivers).

And there's a few reasons why it was/is enabled by default:

1. Speed. A prepared statement is sent separately to the server, holding only the placeholders, and the data is sent in another round. More network roundtrips means slower responses, and emulation spares at least one "command" to the server each time. (Pro tip: If your query is 100% hard-coded and contains no inputs at all, you can use exec() to directly execute the query in one go)
2. Some of the PDO drivers simply don't support it. It is entirely possible that switching to real prepared statement just errors and you have no choice.
3. When done properly, simple escaping is fine (an argument to why one would opt for the performance improvement).

CodeIgniter does emulated prepares, and I promise - they're safe, no less than how PDO does it. But the reason why is not any of the above (well, party the 3rd) ...

See, CI 3 is basically CI 2 without all the bugs, and I don't know how much, but a large part of CI 2 was CI 1.something. And back then, the whole thing was designed to use escapes, because that was simply the norm back then - I've been involved in the project for over 6 years and that was before my time. So every new feature on the way up that touches a database has relied on that. By the time we (well, me) decided that we want to use prepared statements, that was already impossible without huge BC breaks.
We can rework query() and most of the helper methods, but major parts of the Query Builder are impossible to switch. Features will be cut when we do enforce prepared statements. And that will cause backlash, but if only it was the hard part ... There's a LOT of refactoring to be done, and not much time available to invest in that.