> > Unfortunately with current PDO state this is not possible to be done in a > nice way. > Now PDO have defined just these field types: PDO::PARAM_BOOL, > PDO::PARAM_INT, PDO::PARAM_STR, PDO::PARAM_LOB, PDO::PARAM_NULL. > Last one is “wrong” and should be removed. NULL is a state, not a type or > a value. See #73852 bug. > So PDO should be extended with at least PDO::PARAM_FLOAT to add > floats/double mapping. It needs an RFC to be extended. > In plans is to add yet for booleans, Firebird3 bool data type.
Column data can be treated differently from parameter types. I went through this exercise with pdo_dblib: https://github.com/php/php-src/blob/master/ext/pdo_dblib/dblib_stmt.c#L254 It's a little clunky to deal with the pointers correctly, but if Firebird reports a type, you might as well honor it. I didn't realize until you posted this change that PDO core would cast to ints in some cases. It made me wonder if that code should deal with other types or whether all type handling should be pushed into the drivers. Definitely a separate topic, though... Regarding additional parameter types, it's on my todo to write up an RFC to cover some ambiguous cases: - Binary data (see https://bugs.php.net/bug.php?id=47982) - Floating point numbers (see https://www.mail-archive. com/internals@lists.php.net/msg89591.html <https://www.mail-archive.com/internals@lists.php.net/msg89591.html>) - Unicode (touched on with https://www.mail-archive.com/internals@lists.php.net/msg88713.html) My perspective is mainly as someone who works with pdo_dblib. Emulated prepares make a greater degree of control more desirable in some cases. I need to think through how such types would impact other drivers, and I've unfortunately been short on time for the exercise. Adam
