Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121578
MIME-Version: 1.0
References: <734FB3C6-EBE6-4F35-8738-436AF7D8B161@sakiot.com>
In-Reply-To: <734FB3C6-EBE6-4F35-8738-436AF7D8B161@sakiot.com>
Date: Sat, 4 Nov 2023 09:56:14 +0100
Message-ID: <CAJmy8YHpm+SXXJpvmf1nWuUA9Fc6G-TB-PJgogy8oj83JdeuiA@mail.gmail.com>
To: Saki Takamachi <saki@sakiot.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c0ad3e06094fcb17"
Subject: Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX
From: divinity76@gmail.com (Hans Henrik Bergan)

--000000000000c0ad3e06094fcb17
Content-Type: text/plain; charset="UTF-8"

I had no idea PDO's PARAM_INT and PARAM_BOOL was so buggy, good catch!

On Sat, Nov 4, 2023, 07:59 Saki Takamachi <saki@sakiot.com> wrote:

> 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
>
> First, I tried fixed pdo_pgsql.
> https://github.com/php/php-src/pull/12605
>
> Eventually I plan to make similar changes to all bundled pdos.
>
> What do you think about these? If there is a reason for the current
> implementation that should not be changed, it would be very helpful if you
> could tell me why.
>
> Also, if an RFC is required, it would be helpful if you could point it out
> as well. Personally, I don't think an RFC is necessary since this is some
> kind of bug fix. However, I believe the target should be the master branch
> as it changes the user experience somewhat.
>
> [*] I'm not thinking about LOB here, but once I leave them with their
> existing behavior, I change the behavior of other types. Because LOB have
> complex behavior, the scope becomes too large. After making this change, I
> will test again and post another issue if necessary.
>
> [*] I would like the type of PARAM_BOOL to be exactly bool, but this would
> also require changing the behavior of the emulator, and I would not be able
> to issue a PR for each driver, making the scope too large. For this as
> well, I will just align it to `int(1)` or `string(1) 't'`, etc., and once
> these changes are completed, I will verify it and post an issue.
>
> [*] odbc etc. are not compatible with emulation in the first place. There
> are no plans to change this in this context.
>
> Regards.
>
> Saki
>

--000000000000c0ad3e06094fcb17--