Re: [GENERAL] CURRENT_TIMESTAMP

Manfred,

> C2: The returned value has to represent a point in time *during* the
> execution of the SQL-statement.
> 
> The only thing an implementor is free to choose is which point in time
> "during the execution of the SQL-statement" is to be returned, i.e. a
> timestamp in the interval between the start of the statement and the
> first time when the value is needed.
> 
> The current implementation only conforms to C1.

I, for one, would judge that the start time of the statement is "during the 
execution"; it would only NOT be "during the execution" if it was a value 
*before* the start time of the statement.  It's a semantic argument.

The spec is, IMHO, rather vague on how this would relate to transactions.  I 
do not find it at all inconsitent that Bruce, Thomas, and co. interpreted a 
transaction to be an extension of an individual SQL statement for this 
purpose (at least, that's what I guess they did).

Thus, if you accept the postulates that:
1) "During" a SQL statement includes the start time of the statement, and
2) A Transaction is the equivalent of a single SQL statement for many 
purposes, 
Then the current behavior is a logical conclusion.

Further, we could not change that behaviour without breaking many people's 
applications.

Ideally, since we get this question a lot, that a compile-time or 
execution-time switch to change the behavior of current_timestamp 
contextually would be nice.   We just need someone who;s interested enough in 
writing one.

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco