Re: [GENERAL] CURRENT_TIMESTAMP

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: josh(at)agliodbs(dot)com, Manfred Koizar <mkoi-pg(at)aon(dot)at>, Aaron Held <aaron(at)MetroNY(dot)com>, Roberto Mello <rmello(at)cc(dot)usu(dot)edu>, Neil Conway <neilc(at)samurai(dot)com>, pgsql-sql(at)postgresql(dot)org
Subject: Re: [GENERAL] CURRENT_TIMESTAMP
Date: 2002-09-24 00:11:26
Message-ID: 200209240011.g8O0BVL11014@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers 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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2002-09-24 00:27:56 Re: [SQL] Monitoring a Query
Previous Message Patrick Welche 2002-09-23 23:19:18 Re: cvs source doco

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-09-24 00:25:14 BETA2 HOLD: was Re: NUMERIC's transcendental functions
Previous Message Gavin Sherry 2002-09-23 23:16:58 Re: Temp tables and LRU-K caching

Browse pgsql-sql by date

  From Date Subject
Next Message Bruce Momjian 2002-09-24 00:27:56 Re: [SQL] Monitoring a Query
Previous Message John Gilson 2002-09-23 23:46:14 Re: HELP w/ SQL -- distinct select with non distinct fields?