Re: [GENERAL] CURRENT_TIMESTAMP - Mailing list pgsql-sql
From | Bruce Momjian |
---|---|
Subject | Re: [GENERAL] CURRENT_TIMESTAMP |
Date | |
Msg-id | 200209240011.g8O0BVL11014@candle.pha.pa.us Whole thread Raw |
In response to | Re: [GENERAL] CURRENT_TIMESTAMP (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: [GENERAL] CURRENT_TIMESTAMP
(Tom Lane <tgl@sss.pgh.pa.us>)
|
List | pgsql-sql |
I see what you are saying now --- that even single user statements can trigger multiple statements, so you would have to say transaction start time is time the user query starts. I can see how that seems a little arbitrary. However, don't we have separate paths for user queries and queries sent as part of a rule? --------------------------------------------------------------------------- Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > I don't see how we can defend returning the start of the transaction as > > the current_timestamp. > > Here's an example: > > CREATE RULE foo AS ON INSERT TO mytable DO > ( INSERT INTO log1 VALUES (... , now(), ...); > INSERT INTO log2 VALUES (... , now(), ...) ); > > I think it's important that these commands store the same timestamp in > both log tables (not to mention that any now() being stored into mytable > itself generate that same timestamp). > > If you scale that up just a little bit, you can devise scenarios where > successive client-issued commands (within a single transaction) want to > store the same timestamp. After all, it's only a minor implementation > detail that you chose to fire these logging operations via a rule and > not by client-side logic. > > In short, there are plenty of situations where it's critical for > application correctness that a series of commands all be able to operate > with the same value of now(). I don't think that it's wise for Postgres > to try to decide where within a transaction it's safe to advance now(). > That will inevitably break some applications, and it's not obvious what > the benefit is. > > In short: if you want exact current time, there's timeofday(). If you > want start of transaction time, we've got that. If you want start of > current statement time, I have two questions: why, and exactly how do > you want to define current statement, considering functions, rules, > triggers, and all that other stuff that makes it interesting? > > ISTM that if a client or function wants to record intratransaction > times, it can call timeofday() at the appropriate points for itself. > > regards, tom lane > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073