On Mon, 16 Sep 2013 10:38:03 -0400 Richard Hipp <[email protected]> wrote:
> one can easily imagine that one or > more of those two million applications does something like this: > > SELECT current_timestamp, * FROM tab; > > And then runs sqlite3_step() every five or ten seconds in a background > process to fetch a new row, and expects the timestamp on each row to > reflect the actual time of retrieval from disk. It is easy to imagine. It's also broken by design. The simple and correct way to get new data is to issue a new query. Something that runs every 5 or 10 seconds to return a single row isn't going to suffer from re-executing the query. Quite often when someone on this list suggest a feature, the answer is there are N million applications using SQLite and a nonzero probability of breaking one if current behavior changes. The question arises: under what circumstances should the behavior change anyway? Or must every error be defended as a feature? While it's true that something might break, it's also unlikely the current feature set is pareto-optimal. That is, there are would-be users who don't choose SQLite because of missing/broken features, and there are existing users who are forced to know about and work around problems that might be relied on by others. I suggest that when the observed behavior is known to be at variance with what is specified in the SQL standard, it should be viewed as a defect and as a candidate for revision. If it also fails on theoretical grounds -- as when atomicity is promised but not supplied -- it should be added to the list of known bugs until it's rectified. Application of such a standard would guide SQLite in the direction of standards compliance and formal correctness. I cannot but think that would benefit all its users, present and future. --jkl _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
