On 30 Oct 2019, at 3:58am, Keith Medcalf <[email protected]> wrote:
> Before you change anything, I think that is incorrect for the various
> datetime functions. I think they SHOULD be permitted in CHECK constraints
> and in generated always columns, whether those are stored or virtual, whether
> or not parameters are given since they are constant. They should not be
> permitted in indexes however unless they are pure (deterministic).
But can SQLite tell the difference at that stage ? For instance,
julianday('2019-10-30') is deterministic
julianday('now') is non-deteerministic
Using 'now' as an argument gives different results for the same parameter
values. Worse still, the 'now' may not be explicit, you may have a table
column with '2019-10-30' in one row and 'now' in another.
SQLite cannot make the distinction. SQLITE_DETERMINISTIC applies to all values
of the parameters of a function. And since at least one value can yield
different results, julianday() has to be marked as non-deterministic.
The standard way to handle this is that instead understanding the string 'now'
you have a function now() marked as non-deterministic. Then julianday() can be
marked as deterministic. But it's too late for that.
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
