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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
