Date: Thu, 3 Oct 2002 18:03:19 -0400
From: Andrew Sullivan <andrew@libertyrms.info>
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
Message-ID: <20021003180319.Z18497@mail.libertyrms.com>
Mail-Followup-To: Andrew Sullivan <andrew@libertyrms.info>,
	PostgreSQL-development <pgsql-hackers@postgreSQL.org>
References: <11772.1033421161@sss.pgh.pa.us>
	<200210032018.g93KI8110524@candle.pha.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200210032018.g93KI8110524@candle.pha.pa.us>;
	from pgman@candle.pha.pa.us on Thu, Oct 03, 2002 at 04:18:08PM
	-0400

On Thu, Oct 03, 2002 at 04:18:08PM -0400, Bruce Momjian wrote:
> 
> 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. 

A disadvantage to this, as I see it, is that users may have depended on
the traditional Postgres behaviour of time "freezing" in transaction. 
You always had to select timeofday() for moving time.  I can see an
advantage in making what Postgres does somewhat more like what other
people do (as flat-out silly as some of that seems to be).  Still, it
looks to me like the present CURRENT_TIMESTAMP implementation is at
least as much like the spec as anyone else's implementation, and more
like the spec than many of them.  So I'm still not clear on what
problem the change is going to fix, especially since it breaks with
traditional behaviour.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew@libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110