On 6/9/05, Jeremiah Gowdy wrote:
> 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
> 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
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
> 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?
> 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.