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.
