In response to this comment , in off-topic , even though this is not the Stack Overflow template, but valid in my opinion, so that doubts sourced from a comment made more broadly and completely.
PHP is an interpreted language, everything you do with it is by definition slower than compiled resources, in this case the PDO. Without it, you would suddenly need to do nested loops (bad), complex logics (worse), manipulation of arrays (which in a nested loop can be a death sentence).
If your application today uses MySQL, it will always use MySQL and there is no way to use another DBMS for whatever reason, almost always does not justify using the PDO, given that MySQLi gives and leaves.
If you do not use the PDO, using the solution presented here although appropriate becomes wrong because you are making your application dependent on a very large resource for a very small, relatively speaking task.
The framework issue is a bit more delicate.
A framework, either full-stack or domain-specific, aims to solve all the problems of the programmer by it (full stack) or all problems of a certain area (specific domain).
Whatever the case, solving problems related to data access requires considering multiple scenarios because data can come from anywhere (database, XML, TXT, WebService ...).
Let's forget about all other media and focus only on databases. A framework should consider MySQL, PostgreeSQL, SQLite, MSQL among others. And even before the PDO each database was manipulated by a different library, with a syntax and / or, mainly, a different signature of methods / functions.
The PDO came to eliminate half of the problem by standardizing the operations it supports through the same interface, so the programmer would only worry about the pseudo-SQL language itself, since they vary between different DBMSs. >
Now I get where I wanted to go. PHP is getting in the way gradually, but by itself, perhaps even by the excess of legacy that it carries until today, it still has ugly, confusing or even very verbose method signatures (GD that says so). >
While some frameworks do not care about this and allow the PDO constants to be used normally in the respective fetching methods of the results, simply directing all the arguments received to the right one - one of the few func_get_args () - other frameworks go further and try to order in the house.
It works, of course, but if you're using PDO, you're theoretically doing it because you might need another DBMS in the future, even if it's not in practice.
And as I mentioned above there are differences between DBMSs, and suddenly this technique may not be available or even completely implemented in an Informix database (whatever it is) in the same way it is for MySQL .
Some frameworks go even further and try to get around this type of problem. Others, "simply" (because it's not simple at all), rewrite the entire PDO interface.
I have done this in the past, rewriting in an object-oriented model, renaming methods, changing the order of the arguments, rearranging the mess that was left here and there ...
I will not say that what I did was right, wrong, better or worse, but because it is a good case, but very specific indeed, the solution presented may not work in my code because, perhaps, which I may have missed.