When a query is structured (generated), easily getting the final value has merit. This is especially true when you need to see how the bound parameters were substituted, which might occur in a different file or function, therefore, having the ability to fetch that clearly adds value, in my opinion.
One other scenario can be audit trails and logging, if you wanted to capture changes made for update/insert operations without actually capturing the data, using $stmt->getAttribute(Pdo\Sqlite::ATTR_SQL); to get the query without the data could also be a valid use-case for this functionality. I am somewhat curios as to the reasoning for the objection, give that the functionality does not add any meaningful complexity, performance impact or any other conceivable downsides I can think of, perhaps you can share some your reasoning? On Fri, Apr 3, 2026 at 11:38 AM Kamil Tekiela <[email protected]> wrote: > On Fri, 3 Apr 2026 at 16:29, Ilia <[email protected]> wrote: > > > > 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 > > That's the thing. I still don't understand what kind of code would > necessitate the use of this function. What would the debugging code > look like? Why can it not be achieved with the existing functionality? > > Not everything deserves to be brought from SQLite3 to PDO. > -- Ilia Alshanetsky Technologist, CTO, Entrepreneur E: [email protected] T: @iliaa B: http://ilia.ws
