From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200209240037.g8O0bwM14523@candle.pha.pa.us>
Subject: Re: [GENERAL] CURRENT_TIMESTAMP
In-Reply-To: <8770.1032827572@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 23 Sep 2002 20:37:58 -0400 (EDT)
Cc: josh@agliodbs.com, Manfred Koizar <mkoi-pg@aon.at>,
	Aaron Held <aaron@MetroNY.com>, Roberto Mello <rmello@cc.usu.edu>,
	Neil Conway <neilc@samurai.com>, pgsql-sql@postgresql.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > 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?
> 
> We could use "time of arrival of the latest client command string",
> if we wanted to do something like this.  My point is that that very
> arbitrarily assumes that those are the significant points within a
> transaction, and that the client has no need to send multiple commands
> that want to insert the same timestamp into different tables.  This is
> an unwarranted assumption about the client's control structure, IMHO.
> 
> A possible compromise is to dissociate now() and current_timestamp,
> allowing the former to be start of transaction and the latter to be
> start of client command.

I was thinking 'transaction_timestamp' for the transaction start time, and
current_timestamp for the statement start time.  I would equate now()
with current_timestamp.

-- 
  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, Pennsylvania 19073