[TYPO3-core] RFC #15457: Add support for prepared queries

[Helmut Hummel]

Hi Xavier,

On 17.08.10 07:12, Xavier Perseguers wrote:
> 
>> Only one comment and one question:
>>
>> I'm not too comfortable with the is_numeric() checks, because what
>> really is meant is what t3lib_div::testInt() delivers; a check for
>> integer. But is_numeric('1.234') also evaluates to true. The least thing
>> I would do, is add a intval() in replaceValuesInQuery() when type is
>> PARAM_INT. But why not enforcing the use of correct integer type and
>> checking it with is_int()? Any downsides?
> 
> Well, actually what we need is a PARAM_FLOAT too which is not available 
> in PDO (where I took idea to start with). Do you see any downside to 
> have either both PARAM_INT and PARAM_FLOAT or PARAM_NUMERIC which 
> handles both? Because in PDO you have to rely on PARAM_STR which I'd 
> prefer not.

Uh, float, I missed that, probably because the naming PARAM_INT suggests
that the param is int ;)

As you pointed out; three solutions:

1. Rename PARAM_INT to PARAM_NUMERIC
2. Introduce PARAM_FLOAT
3. Handle floats as string

To me, 1. and 2. are quite similar, a kind of mixup of types.
I do not like 1. because you loose the easiest to handle data type
(integer), because you must respect float values.

2. might also be tricky, because AFAIK in PHP floats have different
string representation depending on the locale. Although the locale in
question is never set in TYPO3, it does feel strange, that a valid float
might be 1,345 (not meaning onthousandthreehundredfourtyfive but one
point three four five) and the comma having a completely other meaning
in SQL.

Nevertheless I would introduce a PARAM_FLOAT, with the option to decide
how the value is handled when the param is replaced (probably do it like
PDO and handle it like strings?).

Regards Helmut