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-specific 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 On Fri, Apr 3, 2026 at 11:21 AM Kamil Tekiela <[email protected]> wrote: > On Fri, 3 Apr 2026 at 13:29, Ilia <[email protected]> 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 — original SQL text of a prepared statement (via > sqlite3_sql()) > > - Pdo\Sqlite::ATTR_EXPANDED_SQL — SQL with bound parameters inlined (via > sqlite3_expanded_sql()) > > > > $stmt = $db->prepare('SELECT :name AS greeting'); > > $stmt->bindValue(':name', 'hello'); > > $stmt->execute(); > > > > $stmt->getAttribute(Pdo\Sqlite::ATTR_SQL); // "SELECT :name AS > greeting" > > $stmt->getAttribute(Pdo\Sqlite::ATTR_EXPANDED_SQL); // "SELECT 'hello' > AS greeting" > > > > This mirrors SQLite3Stmt::getSQL() from the non-PDO API, but uses PDO's > getAttribute() mechanism rather than adding a driver-specific method. The > attribute 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 > attributes, single driver, no BC impact), but I wanted input from the list. > > > > Thoughts? > > > > -- > > Ilia Alshanetsky > > Technologist, CTO, Entrepreneur > > E: [email protected] > > 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. > -- Ilia Alshanetsky Technologist, CTO, Entrepreneur E: [email protected] T: @iliaa B: http://ilia.ws
