On Sat, 14 Sep 2013 21:56:23 +0400, Yuriy Kaminskiy <[email protected]> wrote:
> >PS from postgresql documentation: >=== cut >http://www.postgresql.org/docs/9.3/static/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT >=== >Since these functions return the start time of the current transaction, their >values do not change during the transaction. This is considered a feature: the >intent is to allow a single transaction to have a consistent notion of the >"current" time, so that multiple modifications within the same transaction bear >the same time stamp. >=== cut === >*That's* way to go. I agree. See also: http://troels.arvin.dk/db/rdbms/#functions-LOCALTIMESTAMP and http://www.andrew.cmu.edu/user/shadow/sql/sql1992.txt page 139, 6.8, General Rules : 3) If an SQL-statement generally contains more than one reference to one or more <datetime value function>s, then all such ref- erences are effectively evaluated simultaneously. Other sources (Interbase) add even more rules: Any statements triggered by a SQL statement (eg: Triggers or Stored Procedures) will evaluate CURRENT_TIME to be the same value. This value persists until the end of the SQL statement. Now, the discussion can be, did the standard really mean a constant timestamp for a statement or for a transaction? I would vote for the latter, but then another value should be available to get the systemtime, for ewxample to be able to register the start- and end time of a transaction. Perhaps that should be the difference between CURRENT_TIME and datetime('now')? just my two cents... -- Groet, Cordialement, Pozdrawiam, Regards, Kees Nuyt _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
