> I am proposing that when a query is received by MySQL, a timestamp could
> be taken immediately, and that timestamp could travel with the query until
> it is actually processed. For delayed inserts, the query would still sit
> in the insert queue, and it would still say NOW(), but when the query
> finally gets executed, NOW() is evaluated simply by returning the
> timestamp of when the query was received, rather than when it was
> processed.
>
> 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? I'm not really
sure it would break CURRENT_TIMESTAMP to have it evaluated when a request is
"received" rather than when it is actually "processed". Does the spec get
down to that level of implementation?
>> If that would break something, another option would be that only insert
>> delayed queries would use the saved timestamp, all other >queries would
>> ignore it.
>
>Wouldn't it be confusing to have different behaviour of the NOW
>function for INSERT and INSERT DELAYED statements?
Yeah, this is probably the worst option.
>> And in the most conservative option, there could be a seperate function
>> like QNOW() or something that returned when the query >was received by
>> the SQL server rather than the normal NOW() processing.
>
>I would prefer this option.
>
>Changing it for NOW() as a whole only makes MySQL deviate further from
>the standard and has backward compatibility issues. Changing it just
>for NOW() in combination with INSERT DELAYED is potentially confusing.
>So if you really need a new function, this seems like the right idea.
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. As long as you do it in a uniform fashion, wouldn't it be an
implementation issue? 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?
