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