Roger Andersson wrote:
> On 02/12/12 20:34, Yuriy Kaminskiy wrote:
>> I wonder, how it will be handled if you issue such request at
>> month/year/...
>> change (23:59.59.999 GMT -> 00:00:00.000 GMT)?
>> Is timestamp for current_date/current_time generated once and cached
>> at start of
>> SELECT evaluation?
>>
>> It is certainly *not* cached for different rows:
>> SELECT *, current_date, current_time, current_time FROM t
>> while($row = $sth -> fetch) { print ++$i," row: @$row"; sleep 5; }
>> 1 row: 0 2012-02-12 19:20:40 19:20:40
>> 2 row: 1 2012-02-12 19:20:40 19:20:40
>> 3 row: 2 2012-02-12 19:20:45 19:20:45
>> 4 row: 3 2012-02-12 19:20:50 19:20:50
>> 5 row: 4 2012-02-12 19:20:55 19:20:55
>> (two first are same due to sqlite [or perl DBI binding?] seems
>> executes one row
>> ahead).
>>
>> But do they use same cached value *within one row*?
>>
>> If not, results may be randomly inconsistent and broken (race condition).
> No idea!
Okey, I looked at sources, and have not found any caching.
If you want trivially triggered case, repetitive execution
SELECT * FROM t WHERE strftime('%f')<>strftime('%f')
needed only about 17 to 100 iteration to hit error and return
non-deterministical row for me.
But same applies to *all other* use of date/time-functions, you'll just need
more (un)luck, and in one happy day
SELECT substr(current_date,...),
substr(current_date,...),
substr(current-date,...)
will result in 31,02,2012 instead of 31,01,2012 (or 01,02,2012).
Don't you think 31'th February is lucky day?
So more than one invocation of date/time-related functions per statement is
certainly buggy :-|
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
