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?
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
