internals:pdo:brainstorming
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
internals:pdo:brainstorming [2009/12/06 13:30] – more documentation eis_os | internals:pdo:brainstorming [2017/09/22 13:28] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 85: | Line 85: | ||
* error handling | * error handling | ||
* nested transaction (emulation) | * nested transaction (emulation) | ||
+ | |||
+ | |||
+ | === Parameter Binding without Preparing === | ||
+ | Allow prepareless binding of parameters for queries, like PostgreSQL PQexecParams. | ||
+ | * queryParam() ? | ||
+ | |||
+ | |||
+ | |||
===== PDO Binding behaviour (5.3) ===== | ===== PDO Binding behaviour (5.3) ===== | ||
Line 111: | Line 119: | ||
for all bindValue/ | for all bindValue/ | ||
+ | |||
+ | === Why do we need improvements to binding? === | ||
+ | Currently has no standard or agreement how parameters like PDO_PARAM_BOOL should be handled on the user side or the internal PDO drivers. | ||
+ | There are even disagreements between PDOs code comment, explaining PDO_PARAM_INT is the internal PHP type, and the manual telling us it's the database native type. | ||
+ | The result is there is no agreement how even simple parameters should be bound properly and so each driver does it's own guessing how parameters are handled. | ||
+ | |||
+ | === The current situation === | ||
+ | There are two basic categories how currently driver handle bindings: | ||
+ | Trying to guess the right meaning by the zval type (even if PDO is told to use a certain type) | ||
+ | Or try to convert it to string and let the database handle most stuff. | ||
+ | |||
+ | So each driver needs some special care when binding, generally for PDO mysql you need to cast to the right type as setting the binding type constant has no affect. | ||
+ | The PDO core already convert doubles to string in the pdo_stmt.c really_register_bound_param function. | ||
+ | The current code may or may not separate the zval, so the contents of the variable may change after a successful binding or executing of a statement. | ||
+ | |||
+ | |||
+ | === Proposal === | ||
+ | PDO should enforce the zval type in really_register_bound_param so drivers will get a pre-filtered parameters | ||
+ | |||
+ | This would mean: | ||
+ | PDO_PARAM_* will map to internal PHP types, as the code comments in the enum pdo_param_type already tells us. | ||
+ | PDO_PARAM_ZVAL will be introduced to user space to let zvals pass directly. | ||
+ | |||
+ | If the zval type isn't right, PDO should do a zval separation before converting so no user space variables will be altered. | ||
+ | |||
+ | PDO_PARAM_DOUBLE should be introduced later to complete the current support. | ||
+ | |||
+ | |||
+ | === Problems === | ||
+ | PostgreSQL: Currently it's possible to pass a string like " | ||
+ | the string contents will be evaluated by the pdo driver, so " | ||
+ | |||
+ | As soon as PDO Core enforces types and simply use convert_to_boolean bindValue(': | ||
+ | |||
+ | But as bindValue defaults to PDO:: | ||
+ | |||
+ | |||
+ | === Workarounds === | ||
+ | Possible workaround: A special convert_to_boolean function to support SQL FALSE and NO as zend false, however this would be unnatural to PHP core. | ||
+ | |||
+ | |||
+ | === Matrix === | ||
| zval/ | | zval/ | ||
^ IS_NULL | ^ IS_NULL | ||
Line 127: | Line 177: | ||
(3) Allowing streams | (3) Allowing streams | ||
- | For compatibility the execute() function could be changed to PDO_PARAM_AUTO | + | For compatibility the execute() function could be changed to PDO_PARAM_ZVAL |
internals/pdo/brainstorming.1260106236.txt.gz · Last modified: 2017/09/22 13:28 (external edit)