Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id BED174766DE for ; Sun, 29 Sep 2002 00:36:06 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 286BC476693 for ; Sun, 29 Sep 2002 00:36:06 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id g8T4ZrhR008141; Sun, 29 Sep 2002 00:35:53 -0400 (EDT) To: Martijn van Oosterhout Cc: Bruce Momjian , Manfred Koizar , Roland Roberts , pgsql-sql@postgresql.org, pgsql-general@postgresql.org Subject: Re: [SQL] CURRENT_TIMESTAMP In-reply-to: <20020929041007.GB6199@svana.org> References: <20020929034706.GA6199@svana.org> <200209290351.g8T3pW920188@candle.pha.pa.us> <20020929041007.GB6199@svana.org> Comments: In-reply-to Martijn van Oosterhout message dated "Sun, 29 Sep 2002 14:10:07 +1000" Date: Sun, 29 Sep 2002 00:35:53 -0400 Message-ID: <8140.1033274153@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200209/1354 X-Sequence-Number: 30935 Martijn van Oosterhout writes: > On Sat, Sep 28, 2002 at 11:51:32PM -0400, Bruce Momjian wrote: >> 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. One problem with inventing STATEMENT_TIMESTAMP is that (if spelled that way, without parens) it would have to become a fully-reserved keyword, thus possibly breaking some applications that use that name now. But the real point, I think, is that the folks pushing for this think that the standard requires CURRENT_TIMESTAMP to be statement timestamp. Inventing some other keyword isn't going to satisfy them. I don't personally find the "it's required by the spec" argument compelling, because the spec specifically says that the exact behavior is implementation-dependent --- so anyone who assumes CURRENT_TIMESTAMP will behave as start-of-statement timestamp is going to have portability problems anyway. Oracle didn't seem to find the argument compelling either; at last report they have no statement-timestamp function. 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... regards, tom lane