On Tue, 2 Jul 2013 11:57:43 +0100 Simon Slavin <slav...@bigfraud.org> wrote:
> The SELECT statement is fine and consistent. But the SELECT > statement is all of _prepare(), _step(), and _finalize(). Igor is > pointing out that that if you stop before _step() has returned > SQLITE_DONE then you haven?t /done/ a SELECT statement, you?ve just > started one and it is still, in his word, "live". That's very interesting. I've spent many hours reading the SQLite documentation, and just reviewed sqlite3_step(). The only hint I find to that effect is that sqlite3_step "must be called one or more times to *evaluate* the statement" (my emphasis). There is no metion of when locks are established or how atomicity is enforced. It doesn't usually matter, right? The fact that the atomic SELECT is spread out across N function calls is irrelevant if they are executed in uninterrupted sequence, because other connections are blocked from modifying the affected tables until the SELECT is finalized. This weird case is one of (I would say) misusing the connection. IMO SQLite should return an error if prepare is issued on a connection for which a previous prepare was not finalized or reset. That would forestall discussions like, this and prevent confusion and error. > > So I still don't see how the SELECT could be anything > > undeterministic. > > It's not predictable in any simple way because its behaviour changes > depending on lots of things like whether there?s a covering index, > and what other threads do things with the database and when. So you > can't write a simple set of rules that it?ll always follow: it does > different things under different circumstances. I take that to mean that the information returned is deterministic, but how it is executed and the order in which the rows are returned varies. Acknowledged. I just think it's a bad idea, under any circumstances, to allow the number of columns returned by a SELECT statement to vary during its "evaluation" between steps. --jkl _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
