Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130546
Precedence: list
MIME-Version: 1.0
References: <CALkpNnS0_9T421vjBoYxuqYKZoSWUMuOp7vGKCtQbZpSp17ivw@mail.gmail.com>
 <CAGBsUrcq9RVMrefh83bpc9hJ_AHGn=sU1cjuiAFkquTDo9krnQ@mail.gmail.com> <CALkpNnT=BFa1C6TXXfGm7EeNsRP8XcnpkX0W+U4t86--vs+RqA@mail.gmail.com>
In-Reply-To: <CALkpNnT=BFa1C6TXXfGm7EeNsRP8XcnpkX0W+U4t86--vs+RqA@mail.gmail.com>
Date: Fri, 3 Apr 2026 16:38:36 +0100
Message-ID: <CAGBsUrdkwonX5bDZzt0edjmWW5O4-qu5sq--wutpKuwLMYW5bg@mail.gmail.com>
Subject: Re: [PHP-DEV] PDO SQLite: statement attributes for SQL text retrieval
To: Ilia <ilia@ilia.ws>
Cc: PHP Developers Mailing List <internals@lists.php.net>, saki@php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: tekiela246@gmail.com (Kamil Tekiela)

On Fri, 3 Apr 2026 at 16:29, Ilia <ilia@ilia.ws> wrote:
>
> In the context of the SQLite extension, this makes 100% sense as a separa=
te function. In the context of PDO which tries to be generic when fetching =
essentially meta-data IMO it makes more sense to fetch via the attribute fr=
amework which is generic as opposed to creating driver-specific functions.
>
> In terms of utility this primarily be helpful for debugging / analysis pu=
rposes and completes the driver implementation, making what PDO offers matc=
h what the native extension offers. It doesn't impact performance etc... so=
 no negative effect that I can see

That's the thing. I still don't understand what kind of code would
necessitate the use of this function. What would the debugging code
look like? Why can it not be achieved with the existing functionality?

Not everything deserves to be brought from SQLite3 to PDO.