Convert types for bound parameters (next try)
[email protected] (Oskar Eisemuth) Sat, 12 Jun 2010 20:25:40 +0200
| Newsgroups | php.pdo |
|---|---|
| Message-ID | <[email protected]> |
Hello
As no one really was against fixing PDO type converting behavior I
started to write a patch to see if the concept can be introduced into
PDO core.
The new code that I want to introduce to really_register_bound_param, -
here PDO already tries to fix some problems already- , will convert
PDO_PARAM_* always to right type via convert_to_*
The current differences, as soon as the parameter is marked
PDO_PARAM_INPUT_OUTPUT the input isn't changed anymore and every ZVAL is
separated via SEPARATE_ZVAL_IF_NOT_REF. I don't think PDO should magical
change the type of a parameter, or I am wrong?
Still there are some questions:
------------------------
PDO_PARAM_BOOL
------------------------
I have written two additional concept code paths for PDO_PARAM_BOOL now:
a) Strict SQL:
Only accept 1/0, true/false y/n, t/f, anything other will result into an
warning and setting to boolean false. (case insensitive)
b) Lazy SQL: Anything that is a string is boolean true except if it's a
empry string, "0", "false", "False", "FALSE", "f", "F", "No", "no", "n"
or "N".
c) convert_to_boolean
May result in problems with any driver that passes the string data to
the db and using strings.As example bindValue(1, "FALSE",
PDO::PARAM_BOOL) would change to boolean true.
Postgre:
Using c) may be a BC break with postgre sql, only a) and b) would mimic
the old behavior. The question is really here how many people use a
string with PDO::PARAM_BOOL?
MySQL:
Broken by design, PDO_PARAM_* is always PDO_PARAM_ZVAL currently. I
think that would be a bug fix.
SQLite:
You will lose the ability to pass integers as PDO_PARAM_BOOL. Not really
dramatic...
My favorite is convert_to_boolean as it has the least code to maintain
and is natural to PHP.
------------------------
PDO_PARAM_INT:
------------------------
Always convert_to_long, we may get a problem here as the php datatype
may be smaller as the database one. On the other hand pdo_param_type says:
/* int as in long (the php native int type).
* If you mark a column as an int, PDO expects get_col to return
* a pointer to a long */
PDO_PARAM_INT,
Here we have disagreement between the code documentation and the manual.
And http://www.php.net/~wez/pdo/pdo-spec.html#drivers.stmt. is empty. Wez?
Fixing the whole problem in PDO Core may result in copied zvals but
clearly pave the route to a more defined standard between databases...
---
Oskar Eisemuth