Re: PDO SQLite: statement attributes for SQL text retrieval

> Sorry my bad. PHP convention is a bit different from the mail client default. I will improve, > but habits take a while to break, so I can't promise this is the last one :) No worries, I make that kind of mistake all the time too :) > This is a slightly different functionality and connotation as you've correctly pointed > out. Therefore, it definitely warrants having it due to the different functionality/capability. Implementing every feature that exists would increase the maintenance burden on the codebase, so it may be worth being a little cautious in deciding whether this should be implemented. I suspect this is probably something Kamil is also concerned about. Of course, if a good use case becomes clear in the discussion going forward, I would not oppose implementing it. > I don't feel strongly about one way or the other. I'm happy to revise this into a > function if the consensus is that everyone is more comfortable with parameters allowing either > pre/post binding state to be returned, probably defaulting to the pre-binding state. > I don't think 2 methods are needed for functionality that is functionally very similar. > > That being said, I still prefer an attribute because this isn't an actionable function > (like sqliteCreateFunction) but rather something that retrieves information, which to me seems more > appropriate for attribute retrieval similar to Pdo\Pgsql::ATTR_RESULT_MEMORY_SIZE for example. > I don't think this warrants its own function and the value of setting a return type seems > minimal. > Looking at pdo/PgSQL and pdo/SQlite they both limit custom functions to things that change > data. However, pdo/MySQL and pdo/Firebird break the convention, each has a single custom function > for info retrieval, so there isn't technically as convention universally followed convention > here. I’m sorry, I just realized something very important. The place where this should be implemented is the statement class, not the driver, right? Drivers have subclasses, but statements do not. So implementing this as a specialized method would not really be very practical after all… One possible approach would be to add a method on the driver and pass the statement as an argument, but that seems very confusing to me. So in this case, the implementation approach used in your PR may be the only realistic option after all… Regards, Saki