From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <200210032018.g93KI8110524@candle.pha.pa.us>
Subject: Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
In-Reply-To: <11772.1033421161@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 3 Oct 2002 16:18:08 -0400 (EDT)
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII


[ Thread moved to hackers.]

OK, I have enough information from the various other databases to make a
proposal.  It seems the other databases, particularly Oracle, record
CURRENT_TIMESTAMP as the time of statement start.  However, it isn't the
time of statement start from the user's perspective, but rather from the
database's perspective, i.e. if you call a function that has two
statements in it, each statement could have a different
CURRENT_TIMESTAMP.

I don't think that is standards-compliant, and I don't think any of our
users want that.  What they probably want is to have a fixed
CURRENT_TIMESTAMP from the time the query is submitted until it is
completed.  We can call that the "statement arrival time" version of
CURRENT_TIMESTAMP.  I don't know if any of the other databases support
this concept, but it seems the most useful, and is closer to the
standards and to other databases than we are now.

So, we have a couple of decisions to make:

	Should CURRENT_TIMESTAMP be changed to "statement arrival time"?
	Should now() be changed the same way?
	If not, should now() and CURRENT_TIMESTAMP return the same type of
	value?

One idea is to change CURRENT_TIMESTAMP to "statement arrival time", and
leave now() as transaction start time. 

Also, should we added now("val") where val can be "transaction",
"statement", or "clock"?

-- 
  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