Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 7B1BE475B8F for ; Mon, 23 Sep 2002 16:35:41 -0400 (EDT) Received: from davinci.ethosmedia.com (davinci.ethosmedia.com [209.10.40.250]) by postgresql.org (Postfix) with ESMTP id B0B96475843 for ; Mon, 23 Sep 2002 16:35:40 -0400 (EDT) Received: from [66.219.92.2] (HELO chocolate-mousse) by davinci.ethosmedia.com (CommuniGate Pro SMTP 3.5.9) with ESMTP id 1658002; Mon, 23 Sep 2002 13:35:40 -0700 Content-Type: text/plain; charset="iso-8859-1" From: Josh Berkus Reply-To: josh@agliodbs.com Organization: Aglio Database Solutions To: Manfred Koizar , Tom Lane Subject: Re: [GENERAL] CURRENT_TIMESTAMP Date: Mon, 23 Sep 2002 13:36:59 -0700 X-Mailer: KMail [version 1.4] Cc: Bruce Momjian , Aaron Held , Roberto Mello , Neil Conway , pgsql-sql@postgresql.org References: <21724.1032793386@sss.pgh.pa.us> <22827.1032800742@sss.pgh.pa.us> In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200209231336.59105.josh@agliodbs.com> X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200209/274 X-Sequence-Number: 9551 Manfred, > C2: The returned value has to represent a point in time *during* the > execution of the SQL-statement. >=20 > The only thing an implementor is free to choose is which point in time > "during the execution of the SQL-statement" is to be returned, i.e. a > timestamp in the interval between the start of the statement and the > first time when the value is needed. >=20 > The current implementation only conforms to C1. I, for one, would judge that the start time of the statement is "during the= =20 execution"; it would only NOT be "during the execution" if it was a value= =20 *before* the start time of the statement. It's a semantic argument. The spec is, IMHO, rather vague on how this would relate to transactions. = I=20 do not find it at all inconsitent that Bruce, Thomas, and co. interpreted a= =20 transaction to be an extension of an individual SQL statement for this=20 purpose (at least, that's what I guess they did). Thus, if you accept the postulates that: 1) "During" a SQL statement includes the start time of the statement, and 2) A Transaction is the equivalent of a single SQL statement for many=20 purposes,=20 Then the current behavior is a logical conclusion. Further, we could not change that behaviour without breaking many people's= =20 applications. Ideally, since we get this question a lot, that a compile-time or=20 execution-time switch to change the behavior of current_timestamp=20 contextually would be nice. We just need someone who;s interested enough = in=20 writing one. --=20 -Josh Berkus Aglio Database Solutions San Francisco