Re: [SQL] CURRENT_TIMESTAMP - Mailing list pgsql-general

From Martijn van Oosterhout
Subject Re: [SQL] CURRENT_TIMESTAMP
Date
Msg-id 20020929041007.GB6199@svana.org
Whole thread Raw
In response to Re: [SQL] CURRENT_TIMESTAMP  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [SQL] CURRENT_TIMESTAMP  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Sat, Sep 28, 2002 at 11:51:32PM -0400, Bruce Momjian wrote:
> Martijn van Oosterhout wrote:
> > Well, I'd rather it didn't change at all. IMHO it's a feature, not a bug. In
> > any case, if it does get changed we'll have to go through the documentation
> > and work out whether we mean current_timestamp or now(). I think most people
> > actually want now().
>
> Well, I think we have to offer statement start time somewhere, and it
> seems the standard probably requires that.  Two other databases do it
> that way.  Oracle doesn't have CURRENT_TIMESTAMP in 8.X.  Can anyone
> test on 9.X?

Hmm, well having a statement start time could be conceivably useful.

> > Fortunatly where I work we only use now() so it won't really matter too
> > much. Is there a compelling reason to change?
>
> Yes, it will split now() and CURRENT_TIMESTAMP.  I personally would be
> happy with STATEMENT_TIMESTAMP, but because the standard requires it we
> may just have to fix CURRENT_TIMESTAMP.

Well, my vote would be for STATEMENT_TIMESTAMP. Is there really no other
database that does it the way we do? Perhaps it could be matched with a
TRANSACTION_TIMESTAMP and we can sort out CURRENT_TIMESTAMP some other way.

--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> There are 10 kinds of people in the world, those that can do binary
> arithmetic and those that can't.

pgsql-general by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [SQL] CURRENT_TIMESTAMP
Next
From: Tom Lane
Date:
Subject: Re: [SQL] CURRENT_TIMESTAMP