> 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?
Hi Ilia, First of all, one quick note: there is a convention here that you should not post above the quoted text, so please keep that in mind. As a basic premise, retrieving the SQL is already possible at present: ``` $sql = $stmt->queryString; ``` What you are trying to implement for SQLite this time makes it possible to retrieve the SQL in either its pre-binding or post-binding state, so it is slightly more capable than the property above. That said, these are almost certainly very similar features, and from the user’s point of view, being able to retrieve SQL from a property in one case and from an attribute in another may feel somewhat inconsistent. (I would also add that, personally, SQL does not feel like an “attribute” to me.) If so, I think it would be better to make these new features methods instead, which would also make it clearer that they are SQLite-specific functionality. This has another advantage as well: it would make it possible to declare the return type explicitly. Regards, Saki
