Message-ID: <3D9899F9.72BD773A@nsd.ca>
Date: Mon, 30 Sep 2002 14:37:45 -0400
From: Jean-Luc Lachance <jllachan@nsd.ca>
MIME-Version: 1.0
To: josh@agliodbs.com
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Martijn van Oosterhout <kleptog@svana.org>,
	Bruce Momjian <pgman@candle.pha.pa.us>, Manfred Koizar <mkoi-pg@aon.at>,
	Roland Roberts <roland@astrofoto.org>, pgsql-sql@postgresql.org,
	pgsql-general@postgresql.org
Subject: Re: [SQL] CURRENT_TIMESTAMP
References: <20020929034706.GA6199@svana.org>
 <20020929041007.GB6199@svana.org>
	<8140.1033274153@sss.pgh.pa.us>
	<200209291243.45747.josh@agliodbs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

How can you make a difference between now('statement'), and
now('immediate').
To me they are the same thing. Why not simply now() for transaction, and
now('CLOCK') or better yet system_clock() or clock() for curent time.

JLL

Josh Berkus wrote:
> 
> Tom,
> 
> > I'd be happier with the whole thing if anyone had exhibited a convincing
> > use-case for statement timestamp.  So far I've not seen any actual
> > examples of situations that are not better served by either transaction
> > timestamp or true current time.  And the spec is perfectly clear that
> > CURRENT_TIMESTAMP does not mean true current time...
> 
> Are we still planning on putting the three different versions of now() on the
> TODO?  I.e.,
> now('transaction'),
> now('statement'), and
> now('immediate')
> With now() = now('transaction')?
> 
> I still think it's a good idea, provided that we have some easy means to
> determine now('statement').
> 
> --
> -Josh Berkus
>  Aglio Database Solutions
>  San Francisco
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org