Op 15 sep 2013, om 14:05 heeft Stephan Beal het volgende geschreven:
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
anyone every complaining about the current behaviour before. If the
behaviour bothers you, use a user-defined function which provides the
per-db/transaction/whatever behaviour your need. You could have
implemented
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
occur to me to compare CURRENT_TIME to itself because it is, deep down
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.
Although nobody has ever ccomplained it is good to be aware of this
issue/feature.
Combined with other features, like the same expression being
recalculated if referred to more than once, you may see unexpected
results.
I got this on a table of about 1.000 rows:
sqlite> SELECT strftime('%f') AS q FROM t WHERE q <> q;
52.407
52.411
52.413
52.414
sqlite>
Still I can not think of a case where this would be a problem.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
