Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130544
Precedence: list
MIME-Version: 1.0
References: <CALkpNnS0_9T421vjBoYxuqYKZoSWUMuOp7vGKCtQbZpSp17ivw@mail.gmail.com>
In-Reply-To: <CALkpNnS0_9T421vjBoYxuqYKZoSWUMuOp7vGKCtQbZpSp17ivw@mail.gmail.com>
Date: Fri, 3 Apr 2026 16:21:11 +0100
Message-ID: <CAGBsUrcq9RVMrefh83bpc9hJ_AHGn=sU1cjuiAFkquTDo9krnQ@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 13:29, Ilia <ilia@ilia.ws> wrote:
>
> Hi internals,
>
> I'm looking for feedback on a small pdo_sqlite addition.
>
> PR: https://github.com/php/php-src/pull/21456
> Implements: https://github.com/php/php-src/issues/21322
>
> Two new read-only statement attributes on Pdo\Sqlite:
> - Pdo\Sqlite::ATTR_SQL =E2=80=94 original SQL text of a prepared statemen=
t (via sqlite3_sql())
> - Pdo\Sqlite::ATTR_EXPANDED_SQL =E2=80=94 SQL with bound parameters inlin=
ed (via sqlite3_expanded_sql())
>
> $stmt =3D $db->prepare('SELECT :name AS greeting');
> $stmt->bindValue(':name', 'hello');
> $stmt->execute();
>
> $stmt->getAttribute(Pdo\Sqlite::ATTR_SQL);          // "SELECT :name AS g=
reeting"
> $stmt->getAttribute(Pdo\Sqlite::ATTR_EXPANDED_SQL); // "SELECT 'hello' AS=
 greeting"
>
> This mirrors SQLite3Stmt::getSQL() from the non-PDO API, but uses PDO's g=
etAttribute() mechanism rather than adding a driver-specific method. The at=
tribute system is how PDO drivers expose driver-specific functionality, so =
it's a natural fit.
>
> ATTR_EXPANDED_SQL is gated behind a configure check for sqlite3_expanded_=
sql availability.
>
> I don't think this needs a full RFC given the scope (two read-only attrib=
utes, single driver, no BC impact), but I wanted input from the list.
>
> Thoughts?
>
> --
> Ilia Alshanetsky
> Technologist, CTO, Entrepreneur
> E: ilia@ilia.ws
> T: @iliaa
> B: http://ilia.ws

I agree with Saki that a dedicated function would be better than
treating this as an attribute. However, I fail to understand why this
is useful at all. SQL is something that is coming from the developer
using the function, so why would they need to look it up again from
the prepared statement? The emulated statement could be useful in case
an error is triggered due to a data issue, but not only does this
happen rarely, but the error already contains all the necessary
information. I think I would like to see a concrete use case of when
this is helpful.