Re: PDO SQLite: statement attributes for SQL text retrieval

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 — 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: 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.