Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130549
Precedence: list
MIME-Version: 1.0
References: <CALkpNnS=nooF2nMpSvzufm3PtcZpLE9Sx04wEeXOmgtQ=SqGiA@mail.gmail.com>
 <606EDE71-8E63-4626-A509-5E067DA3EACA@sakiot.com>
In-Reply-To: <606EDE71-8E63-4626-A509-5E067DA3EACA@sakiot.com>
Date: Fri, 3 Apr 2026 12:12:08 -0400
Message-ID: <CALkpNnRDJG7bwZ8Mr9jDq+r-mLSJ47SDsGbYA_gCGsm9TSApSQ@mail.gmail.com>
Subject: Re: [PHP-DEV] PDO SQLite: statement attributes for SQL text retrieval
To: Saki Takamachi <saki@sakiot.com>
Cc: Kamil Tekiela <tekiela246@gmail.com>, internals@lists.php.net, saki@php.net
Content-Type: multipart/alternative; boundary="000000000000dbe4b5064e909442"
From: ilia@ilia.ws (Ilia)

--000000000000dbe4b5064e909442
Content-Type: text/plain; charset="UTF-8"

>
> First of all, one quick note: there is a convention here that you should
> not post above the quoted text, so please keep that in mind.
>

Sorry my bad. PHP convention is a bit different from the mail client
default. I will improve, but habits take a while to break, so I can't
promise this is the last one :)


> As a basic premise, retrieving the SQL is already possible at present:
>
> ```
> $sql = $stmt->queryString;
> ```
>
> What you are trying to implement for SQLite this time makes it possible to
> retrieve the SQL in either its pre-binding or post-binding state, so it is
> slightly more capable than the property above.
>

This is a slightly different functionality and connotation as you've
correctly pointed out. Therefore, it definitely warrants having it due to
the different functionality/capability.

If so, I think it would be better to make these new features methods
> instead, which would also make it clearer that they are SQLite-specific
> functionality.
>
> This has another advantage as well: it would make it possible to declare
> the return type explicitly.
>

I don't feel strongly about one way or the other. I'm happy to revise this
into a function if the consensus is that everyone is more comfortable with
parameters allowing either pre/post binding state to be returned, probably
defaulting to the pre-binding state.
I don't think 2 methods are needed for functionality that is functionally
very similar.

That being said, I still prefer an attribute because this isn't an
actionable function (like sqliteCreateFunction) but rather something that
retrieves information, which to me seems more appropriate for attribute
retrieval similar to Pdo\Pgsql::ATTR_RESULT_MEMORY_SIZE for example.
I don't think this warrants its own function and the value of setting a
return type seems minimal.

-- 
Ilia Alshanetsky
Technologist, CTO, Entrepreneur
E: ilia@ilia.ws
T: @iliaa
B: http://ilia.ws

--000000000000dbe4b5064e909442
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">First of all, one quick note: ther=
e is a convention here that you should not post above the quoted text, so p=
lease keep that in mind.<br></blockquote><div><br></div><div>Sorry my bad. =
PHP convention is a bit different from the mail client default. I will impr=
ove, but habits=C2=A0take a while to break, so I can&#39;t promise this is =
the last one :)=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">
As a basic premise, retrieving the SQL is already possible at present:<br>
<br>
```<br>
$sql =3D $stmt-&gt;queryString;<br>
```<br>
<br>
What you are trying to implement for SQLite this time makes it possible to =
retrieve the SQL in either its pre-binding or post-binding state, so it is =
slightly more capable than the property above.<br></blockquote><div><br></d=
iv><div>This is a slightly different functionality and connotation as you&#=
39;ve correctly pointed out. Therefore, it definitely warrants having it du=
e to the different functionality/capability.=C2=A0</div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex">If so, I think it would be be=
tter to make these new features methods instead, which would also make it c=
learer that they are SQLite-specific functionality.<br>
<br>
This has another advantage as well: it would make it possible to declare th=
e return type explicitly.<br></blockquote><div><br></div><div>I don&#39;t f=
eel strongly about one way or the other. I&#39;m happy to revise this into =
a function if the consensus is that everyone is more comfortable with param=
eters allowing either pre/post binding state to be returned, probably defau=
lting to the pre-binding state.</div><div>I don&#39;t think 2 methods are n=
eeded for functionality that is functionally very similar.=C2=A0</div><div>=
<br></div><div>That being said, I still prefer an attribute because this is=
n&#39;t an actionable function (like sqliteCreateFunction) but rather somet=
hing that retrieves information, which to me seems more appropriate for att=
ribute retrieval similar to Pdo\Pgsql::ATTR_RESULT_MEMORY_SIZE for example.=
=C2=A0</div><div>I don&#39;t think this warrants its own function and the v=
alue of setting a return type seems minimal.</div></div><div><br></div><spa=
n class=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"=
gmail_signature"><div dir=3D"ltr">Ilia Alshanetsky<div>Technologist, CTO, E=
ntrepreneur</div><div>E: <a href=3D"mailto:ilia@ilia.ws" target=3D"_blank">=
ilia@ilia.ws</a></div><div>T: @iliaa=C2=A0</div><div>B: <a href=3D"http://i=
lia.ws" target=3D"_blank">http://ilia.ws</a></div></div></div></div>

--000000000000dbe4b5064e909442--