List:General Discussion« Previous MessageNext Message »
From:Jeremiah Gowdy Date:June 9 2005 3:52pm
Subject:Re: INSERT DELAYED and NOW()
View as plain text  
> 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
>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

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?

INSERT DELAYED and NOW()Jeremiah Gowdy9 Jun
  • Re: INSERT DELAYED and NOW()Jeff Smelser9 Jun
  • Re: INSERT DELAYED and NOW()Jeremiah Gowdy9 Jun
  • Re: INSERT DELAYED and NOW()Jochem van Dieten9 Jun
  • Re: INSERT DELAYED and NOW()Jeremiah Gowdy9 Jun
    • Re: INSERT DELAYED and NOW()Jochem van Dieten9 Jun
      • Re: INSERT DELAYED and NOW()Eric Bergen9 Jun
        • Re: INSERT DELAYED and NOW()SGreen9 Jun
          • Re: INSERT DELAYED and NOW()Eric Bergen10 Jun
        • Re: INSERT DELAYED and NOW()Philippe Poelvoorde10 Jun