Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id BC27F4763F0; Sun, 29 Sep 2002 00:13:24 -0400 (EDT) Received: from svana.org (t1-1-076.dialup.apex.net.au [203.20.62.76]) by postgresql.org (Postfix) with ESMTP id CA42C4760AF; Sun, 29 Sep 2002 00:13:23 -0400 (EDT) Received: from kleptog by svana.org with local (Exim 3.35 #1 (Debian)) id 17vVPD-0001nk-00; Sun, 29 Sep 2002 14:10:07 +1000 Date: Sun, 29 Sep 2002 14:10:07 +1000 From: Martijn van Oosterhout To: Bruce Momjian Cc: Manfred Koizar , Roland Roberts , pgsql-sql@postgresql.org, pgsql-general@postgresql.org Subject: Re: [SQL] CURRENT_TIMESTAMP Message-ID: <20020929041007.GB6199@svana.org> Reply-To: Martijn van Oosterhout Mail-Followup-To: Bruce Momjian , Manfred Koizar , Roland Roberts , pgsql-sql@postgresql.org, pgsql-general@postgresql.org References: <20020929034706.GA6199@svana.org> <200209290351.g8T3pW920188@candle.pha.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200209290351.g8T3pW920188@candle.pha.pa.us> User-Agent: Mutt/1.3.28i X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200209/1353 X-Sequence-Number: 30934 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 http://svana.org/kleptog/ > There are 10 kinds of people in the world, those that can do binary > arithmetic and those that can't.