Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130548
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mime-Version: 1.0 (1.0)
Subject: Re: [PHP-DEV] PDO SQLite: statement attributes for SQL text retrieval
Date: Sat, 4 Apr 2026 00:57:49 +0900
Message-ID: <606EDE71-8E63-4626-A509-5E067DA3EACA@sakiot.com>
References: <CALkpNnS=nooF2nMpSvzufm3PtcZpLE9Sx04wEeXOmgtQ=SqGiA@mail.gmail.com>
Cc: Kamil Tekiela <tekiela246@gmail.com>, internals@lists.php.net,
 saki@php.net
In-Reply-To: <CALkpNnS=nooF2nMpSvzufm3PtcZpLE9Sx04wEeXOmgtQ=SqGiA@mail.gmail.com>
To: Ilia <ilia@ilia.ws>
From: saki@sakiot.com (Saki Takamachi)

> 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 parameter=
s were substituted, which might occur in a different file or function, there=
fore, having the ability to fetch that clearly adds value, in my opinion.
>=20
> One other scenario can be audit trails and logging, if you wanted to captu=
re changes made for update/insert operations without actually capturing the d=
ata, using $stmt->getAttribute(Pdo\Sqlite::ATTR_SQL);  to get the query with=
out the data could also be a valid use-case for this functionality.=20
>=20
> I am somewhat curios as to the reasoning for the objection, give that the f=
unctionality does not add any meaningful complexity, performance impact or a=
ny other conceivable downsides I can think of, perhaps you can share some yo=
ur reasoning?

Hi Ilia,

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.

As a basic premise, retrieving the SQL is already possible at present:

```
$sql =3D $stmt->queryString;
```

What you are trying to implement for SQLite this time makes it possible to r=
etrieve the SQL in either its pre-binding or post-binding state, so it is sl=
ightly more capable than the property above.

That said, these are almost certainly very similar features, and from the us=
er=E2=80=99s point of view, being able to retrieve SQL from a property in on=
e case and from an attribute in another may feel somewhat inconsistent.
(I would also add that, personally, SQL does not feel like an =E2=80=9Cattri=
bute=E2=80=9D to me.)

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 functionali=
ty.

This has another advantage as well: it would make it possible to declare the=
 return type explicitly.

Regards,

Saki=