Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130553
Content-Type: text/plain; charset=us-ascii
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
In-Reply-To: <CALkpNnQuXRPckwV2wLAogg_W2AYKRfP4My4g7vhTucDC444V6w@mail.gmail.com>
Cc: Kamil Tekiela <tekiela246@gmail.com>, internals@lists.php.net,
 saki@php.net
Date: Sat, 4 Apr 2026 02:03:19 +0900
Message-ID: <E9F0FC4A-F73C-499A-A5F9-4CD4A4C75D38@sakiot.com>
References: <CALkpNnQuXRPckwV2wLAogg_W2AYKRfP4My4g7vhTucDC444V6w@mail.gmail.com>
To: Ilia <ilia@ilia.ws>
From: saki@sakiot.com (Saki Takamachi)

> Technically yes, but practically I think the complexity of that approach w=
ould likely outweigh its utility, hence the current approach.

OK I see, thank you.

I do not think there is much room left for discussion regarding the implemen=
tation approach.

As for demand, I tried the following search on GitHub code search:

```
/(?-i)->getSQL\(true/ language:PHP
```

It returns roughly 500 hits (although, of course, there is no guarantee that=
 all of them are from the SQLite3 extension).

Looking through the code at a high level, it seems to be used mainly for SQL=
 reuse and debugging.

It is certainly possible to log the SQL before binding and the parameters to=
 be bound separately, but being able to retrieve the actually assembled SQL m=
ay still be convenient.

Regards,

Saki=