Re: [PDO] Fixing bug #44639 for mysql

Hi,

As user, I would expect, no meter what, that if a variable type is
explicitly given that it must be handled in that way.

If I am saying that variable type is integer and I am passing string then
perhaps variable might be converted to integer. However, I would prefer
throwing exception and letting me know that I did something wrong:
"Exception: Declared variable type INTEGER, passed variable type FLOAT (or
whatever)".

Let's say that I am explicitly saying PDO::PARAM_INT and I am passing string
with date. In such case, most likely, date string would be converted to 1 or
0, creating unexpected results and a bug that would be extremely hard to
spot.

We, users (PHP developers) should know what we are doing and if we are
making mistakes, we should be warned instead of guessing our intentions.

Petting lazy developers hugely contribute to wide spreading of MJE (Mumble
Jumble Echo) design pattern. :)

Goran

On Wed, Oct 28, 2009 at 11:29 AM, Matteo Beccati <[email protected]> wrote:

> Hi,
>
> > as for the execute() approach, here it should ideally at least for
> > variables of type integer/float implicitly use PDO::PARAM_INT/FLOAT. if
> > this isnt the case today, then it might be too big of a BC break to do
> > it now.
>
> This was also discussed for a particular PDO_PGSQL problem with
> $stmt->execute(array(false)) failing[1] because Postgres doesn't cast
> the empty string to boolean false, and I gather that the desired
> behaviour is to always ignore the php type. A documentation bug report
> is also availabe[2]. Still I think it should be something we can address
> in PDO2.
>
>
> [1] http://bugs.php.net/bug.php?id=44597
> [2] http://bugs.php.net/bug.php?id=49614
>
>
> Cheers
> --
> Matteo Beccati
>
> --
> PDO Working Group Mailing List (http://pdo.php.net)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>