On 6/9/05, Jeremiah Gowdy wrote: > > > > Does this seem to break SQL / application logic in some fashion? > > >Not worse then it is currently broken :) > > > >According to the SQL standard CURRENT_TIMESTAMP, which in MySQL is a > >synonym for NOW(), is supposed to have a value that does not change > >during a transaction. At which point during the transaction that value > >is 'sampled' is implementation defined. (ISO/IEC 9075:2003-2 section > >6.31) > > > >Since both NOW() and INSERT DELAYED are MySQL extensions I don't > >particularly care how they behave/interfere, but I would prefer any > >solution/hack not to complicate MySQL ever becomming standard > >compliant in this regard (and standard compliance is an official > >goal). > > Does the standard specify when the timestamp is evaluated?
During the transaction. > I agree that it might be better for it to be a seperate function, but since > DELAYED isn't part of the standard, I'm not sure there's anything that keeps > an implementation from evaluating the CURRENT_TIMESTAMP for a query upon > receipt of the query from the network, rather than when the SQL statement is > evaluated. Let me reiterate: "Since both NOW() and INSERT DELAYED are MySQL extensions I don't particularly care how they behave/interfere". > If I wrote a SQL server from scratch, would this not > be a valid implementation, to timestamp upon network receive of a complete > query, rather than upon finding the CURRENT_TIMESTAMP (or NOW()) function > while parsing a query? That depends on some more implementation issues: perceivably your network receive could even be before the start of the transaction. Evaluate CURRENT_TIMESTAMP only once per transaction, between the start of the transaction and the end of the transaction. Jochem -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
