Josh Berkus wrote: > 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.
I don't see how we can defend returning the start of the transaction as the current_timestamp. In a multi-statement transaction, that doesn't seem very current to me. I know there are some advantages to returning the same value for all queries in a transaction, but is that value worth returning such stale time information? -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
