Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130547
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> <CAGBsUrdkwonX5bDZzt0edjmWW5O4-qu5sq--wutpKuwLMYW5bg@mail.gmail.com>
In-Reply-To: <CAGBsUrdkwonX5bDZzt0edjmWW5O4-qu5sq--wutpKuwLMYW5bg@mail.gmail.com>
Date: Fri, 3 Apr 2026 11:48:27 -0400
Message-ID: <CALkpNnS=nooF2nMpSvzufm3PtcZpLE9Sx04wEeXOmgtQ=SqGiA@mail.gmail.com>
Subject: Re: [PHP-DEV] PDO SQLite: statement attributes for SQL text retrieval
To: Kamil Tekiela <tekiela246@gmail.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>, saki@php.net
Content-Type: multipart/alternative; boundary="0000000000002a6c72064e904012"
From: ilia@ilia.ws (Ilia)

--0000000000002a6c72064e904012
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

When a query is structured (generated), easily getting the final value has
merit. This is especially true when you need to see how the bound
parameters were substituted, which might occur in a different file or
function, therefore, having the ability to fetch that clearly adds value,
in my opinion.

One other scenario can be audit trails and logging, if you wanted to
capture changes made for update/insert operations without actually
capturing the data, using $stmt->getAttribute(Pdo\Sqlite::ATTR_SQL);  to
get the query without the data could also be a valid use-case for this
functionality.

I am somewhat curios as to the reasoning for the objection, give that the
functionality does not add any meaningful complexity, performance impact or
any other conceivable downsides I can think of, perhaps you can share some
your reasoning?

On Fri, Apr 3, 2026 at 11:38=E2=80=AFAM Kamil Tekiela <tekiela246@gmail.com=
> wrote:

> 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
> separate 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 framework which is generic as opposed to creating driver-specif=
ic
> functions.
> >
> > In terms of utility this primarily be helpful for debugging / analysis
> purposes and completes the driver implementation, making what PDO offers
> match 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.
>


--=20
Ilia Alshanetsky
Technologist, CTO, Entrepreneur
E: ilia@ilia.ws
T: @iliaa
B: http://ilia.ws

--0000000000002a6c72064e904012
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">When a query is structured (generated), easily getting the=
 final value has merit. This is especially true when you need to see how th=
e bound parameters=C2=A0were substituted, which might occur in a different =
file or function, therefore, having the ability to fetch that clearly adds =
value, in my opinion.<div><br></div><div>One other scenario can be audit tr=
ails and logging, if you wanted to capture changes made for update/insert o=
perations without actually capturing the data, using=C2=A0$stmt-&gt;getAttr=
ibute(Pdo\Sqlite::ATTR_SQL);=C2=A0 to get the query without the data could =
also be a valid use-case for this functionality.=C2=A0</div><div><br></div>=
<div>I am somewhat curios as to the reasoning for the objection, give that =
the functionality does not add any meaningful complexity, performance impac=
t or any other conceivable=C2=A0downsides I can think=C2=A0of, perhaps you =
can share some your reasoning?</div></div><br><div class=3D"gmail_quote gma=
il_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Apr 3, 20=
26 at 11:38=E2=80=AFAM Kamil Tekiela &lt;<a href=3D"mailto:tekiela246@gmail=
.com">tekiela246@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex">On Fri, 3 Apr 2026 at 16:29, Ilia &lt;<a href=3D"=
mailto:ilia@ilia.ws" target=3D"_blank">ilia@ilia.ws</a>&gt; wrote:<br>
&gt;<br>
&gt; In the context of the SQLite extension, this makes 100% sense as a sep=
arate function. In the context of PDO which tries to be generic when fetchi=
ng essentially meta-data IMO it makes more sense to fetch via the attribute=
 framework which is generic as opposed to creating driver-specific function=
s.<br>
&gt;<br>
&gt; In terms of utility this primarily be helpful for debugging / analysis=
 purposes and completes the driver implementation, making what PDO offers m=
atch what the native extension offers. It doesn&#39;t impact performance et=
c... so no negative effect that I can see<br>
<br>
That&#39;s the thing. I still don&#39;t understand what kind of code would<=
br>
necessitate the use of this function. What would the debugging code<br>
look like? Why can it not be achieved with the existing functionality?<br>
<br>
Not everything deserves to be brought from SQLite3 to PDO.<br>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr">Ilia Alshanetsky<div>Technologist, CTO, Entrepre=
neur</div><div>E: <a href=3D"mailto:ilia@ilia.ws" target=3D"_blank">ilia@il=
ia.ws</a></div><div>T: @iliaa=C2=A0</div><div>B: <a href=3D"http://ilia.ws"=
 target=3D"_blank">http://ilia.ws</a></div></div></div>

--0000000000002a6c72064e904012--