Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121580
MIME-Version: 1.0
References: <CANLbj-r3A37mRgp4JGPM0ZTuXg1Tdp660c3LBA-QubHPFjq7bg@mail.gmail.com>
 <DB225C8B-25F0-48A4-B879-ECF7142B848D@sakiot.com>
In-Reply-To: <DB225C8B-25F0-48A4-B879-ECF7142B848D@sakiot.com>
Reply-To: Kentaro Takeda <takeda@youmind.jp>
Date: Sat, 4 Nov 2023 19:46:28 +0900
Message-ID: <CAON3zHAcqGC5hnnLxFfJro0aPEhiLJNyGiP_zvRHsOfb4he3Og@mail.gmail.com>
To: Saki Takamachi <saki@sakiot.com>
Cc: Ayesh Karunaratne <ayesh@php.watch>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX
From: internals@lists.php.net ("Kentaro Takeda via internals")

Hi, internals.

> As shown in the following issue, the behavior of `PDO::PARAM_XXXX` is
> inconsistent and I would like to fix this.
> https://github.com/php/php-src/issues/12603

I consider the current behavior a bug.
And some of them contain behaviors that are very confusing to users.

> It may be an xkcd/1172 case, but these kinds of cases are very hard
> to spot from static analyzers, and are often only surfaced
> in production only if someone spent enough time to dig deep.

As previously discussed by Ayesh, assessing
the users' impact of a fix for this issue might be a little challenging,

but I think it's important to address it to prevent confusion.

Taking PostgreSQL as an example, let's consider the following PHP code:

```php
$pdo =3D new PDO('pgsql:');
$pdo->exec('create temp table t(boolean_column bool, text_column text)');

$stmt =3D $pdo->prepare('insert into t values (:v1, :v2)');
$stmt->bindValue(':v1', false, PDO::PARAM_BOOL);
$stmt->bindValue(':v2', false, PDO::PARAM_BOOL);
$stmt->execute();

$result =3D $pdo->query('select * from t');
var_export($result->fetchAll(PDO::FETCH_ASSOC));
````

The result should look like this:

````
array (
   0 =3D>
   array (
     'boolean_column' =3D> false,
     'text_column' =3D> 'f', // HERE!!!
   ),
)
````

Even if we insert `false`, it will change to `'f'` when we select it.

This is fundamentally a user mistake. However, the big problem in this case=
 is
that the value `'f'` after the change is *truthy*. Who could have predicted
that even though you entered `false`, it ended up being `true` ?

I've seen a lot of pointless code to deal with problems
like this where types are not uniformly formatted.

As Saki says, we need to think carefully about whether
we can accurately treat this as `bool`.
However, regarding the above problem:

* Fix *truthy* / *falsy* such as `int(1)` / `int(0)` to a form that
can be correctly determined.
* Make this behavior consistent across as many drivers as possible.

Even this small fix would eliminate much of the confusion that is
currently occurring.
(Of course, it should ultimately be treated as `bool`.)

I look forward to a resolution that will be satisfactory to all.
Thank you for your attention.

2023=E5=B9=B411=E6=9C=884=E6=97=A5(=E5=9C=9F) 17:56 Saki Takamachi <saki@sa=
kiot.com>:
>
> Hi, Ayesh,
>
> I forgot to tell you one important thing.
>
> Binding of parameters is not actually done in the `bindXXXX`method, but i=
n the `execute()` method. Therefore, when preparing a new method, a slightl=
y larger mechanism is required to determine which method the parameter was =
set through.
>
> Regards.
>
> Saki
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>