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
