There are perhaps 2 million applications in the wild that use SQLite,
so it
will be difficult to check them all. But 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. Causing 'now' to mean
exactly the same time for an entire SQL statement would break such
applications.
As a compromise, the current SQLite trunk causes 'now' to be exactly the
same for all date and time functions within a single sqlite3_step() call.
Perhaps a new connection-wide "pragma freeze_now=ON;" which would
freeze 'now' at the beginning of the next statement and unfreeze it at
the next auto-commit or when processing a "pragma freeze_now=OFF;"
would solve another part of the race issue.
Applications relying on the old behavior don't change and new ones
where the possibility of race is dangerous can avoid it at little cost.
Still some multi-threaded apps would need to consider the implications,
but we all know what you Richard think about threads!
--
JcD
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
