Why PDO :: ATTR_EMULATE_PREPARES => TRUE returns all values ​​as strings

It is somewhat general knowledge that with different versions of php and mysql, as well as using your own prepared statements or emulated prepared statements, you can have value types of type natine or not:

$value = $db->query("SELECT 1033 AS Code")->fetch(PDO::FETCH_COLUMN)
$value2 = $db->query("SELECT '1033' AS Code")->fetch(PDO::FETCH_COLUMN);

//PDO::ATTR_EMULATE_PREPARES set to true:
var_dump($value); // string(4) "1033"
var_dump($value2); // string(4) "1033"

//PDO::ATTR_EMULATE_PREPARES set to false:
var_dump($value); // int(1033)
var_dump($value2); // string(4) "1033"

      

from this article :

The problem is that PDO is causing zval splitting due to the type passed to the string. The cast is requested by the PDO core.

PDO will always pass data to the default string, and the PDO_MYSQL driver can only run on the default of that PDO by returning zvals.

Why will PDO always pass data to a string?

+3


source to share


1 answer


Provided that

PDO will emulate prepared statements / bound options for drivers that don't support them.

... this function (emulated prepared statements) is probably handled by a piece of code that is common to all drivers.

However, based on the fact that functions such as are not implemented for all drivers PDOStatement::getColumnMeta()

,



Not all PDO drivers support PDOStatement :: getColumnMeta ().

... I am assuming that the underlying PDO database cannot determine the type of the database column in consistency, cross-database mode, and therefore must fall back to a generic row type.

Unfortunately, the source code is too obscure for me to test these assumptions.

+2


source







All Articles