Eric Bergen <ebergen@stripped> wrote on 06/09/2005 12:56:59 PM:
> How about something like this:
> mysql> select @t := now();
> +---------------------+
> | @t := now() |
> +---------------------+
> | 2005-06-09 09:55:49 |
> +---------------------+
> 1 row in set (0.00 sec)
> mysql> insert delayed into t set t = @t;
> Query OK, 1 row affected (0.00 sec)
> mysql> select * from t;
> +---------------------+
> | t |
> +---------------------+
> | 2005-06-09 09:55:49 |
> +---------------------+
> 1 row in set (0.01 sec)
>
> This way you get the current time of the call and it doesn't matter how
> long the insert delayed sits for.
> Jochem van Dieten wrote:
> >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
> >
> >
> >
The problem with that is that you have just doubled the query count at the
central logging server. That's a lot of traffic it can probably do
without.
I like the QNOW() approach. (Use an extension, the new function, to deal
with a side effect of an extension, DELAYED. It's a universal balance kind
of thing.)
Some alternative names: QUEUEDNOW(), QUEUEDTIMESTAMP(), RECEIVEDTIME(),
RECEIVEDTIMESTAMP(), ARRIVALTIMESTAMP()
Shawn Green
Database Administrator
Unimin Corporation - Spruce Pine
