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 BerkusAglio Database SolutionsSan Francisco
