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
