Re: [SQL] [GENERAL] CURRENT_TIMESTAMP - Mailing list pgsql-hackers

From Andrew Sullivan
Subject Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
Date
Msg-id 20021003180319.Z18497@mail.libertyrms.com
Whole thread Raw
In response to Re: [SQL] [GENERAL] CURRENT_TIMESTAMP  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [SQL] [GENERAL] CURRENT_TIMESTAMP  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: John Worsley
Date:
Subject: [GENERAL] Small patch for PL/Perl Misbehavior with Runtime Error Reporting
Next
From: Bruce Momjian
Date:
Subject: Re: [SQL] [GENERAL] CURRENT_TIMESTAMP