Stephan Beal wrote: > On Sun, Sep 15, 2013 at 1:58 PM, Yuriy Kaminskiy <yum...@gmail.com> wrote: > >> Sure, there can be several way to interpret CURRENT_* and *('now'). >> However, >> some of them can be useful (transaction, statement), and others (step) - >> cannot >> be. And some (sub-expression, the way it "works" currently) are purely >> insane. >> > > i've been following this list since 2006 or 2007 and i can't remember
Oh, yes, yes, "I was on debian [...] list since [...] and can't remember anyone complaining about broken RNG for two years". So what? And, by the way, I already complained about this behavior on this list in the beginning of 2012 year. > anyone every complaining about the current behaviour before. If the > behaviour bothers you, use a user-defined function which provides the It does not bother *me* - I can happily live with knowledge that SQLite CURRENT_*/*('now') is broken by design and should not be used ever. It should bother people that use sqlite for something serious. > per-db/transaction/whatever behaviour your need. You could have implemented I have not found any way to associate user-defined data with transaction in sqlite API. > it in the time you've expended bemoaning the current (well established, if > perhaps fundamentally flawed) behaviour. > > > where `2*2 <> 4`; using them them in product targeted to to general public >> would >> be insane; using them *randomly* (as it happens with CURRENT_TIME <> >> CURRENT_TIME) - beyond insane. >> > > foo() == foo() > > is never guaranteed to be true unless foo() is a pure function with no > inputs. i consider the current behaviour to be correct. It would never And functions in SQL are *expected* to be pure. > occur to me to compare CURRENT_TIME to itself because it is, deep down Comparing with itself just a method to *easily demonstrate* this bug. In real-world, this bug affect any query where CURRENT_TIME used more than once. E.g. OP's query - `...WHERE day BETWEEN DATE('now',...) AND DATE('now',...)`. This *real-world* query is affected. Even through it does not *directly* compare CURRENT_TIME with CURRENT_TIME. > inside, a C function call which uses time-dependent, system-level state. > i.e. it's a perfect candidate for races. So avoid them, in the same way > that nobody should ever (in C) expect (time(0) == time(0)) to match 100% of > the ... time. In C there are local variables, where you can save result of impure functions when it is important. There are no local variables in SQL - with even more extreme example shown in E.Pasma message nearby - `SELECT strftime('%f') AS q FROM t WHERE q <> q`; oh, by the way, `SELECT CURRENT_TIME AS q FROM t WHERE q <> q` trigger that bug too, I've just checked (and it took less than 2 seconds to trigger). _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users