Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id AD218475E3E for ; Thu, 3 Oct 2002 19:09:47 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 1BCF7475DFF for ; Thu, 3 Oct 2002 19:09:46 -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 g93N9YhR015245; Thu, 3 Oct 2002 19:09:34 -0400 (EDT) To: Bruce Momjian Cc: Andrew Sullivan , PostgreSQL-development Subject: Re: [SQL] [GENERAL] CURRENT_TIMESTAMP In-reply-to: <200210032215.g93MFx823428@candle.pha.pa.us> References: <200210032215.g93MFx823428@candle.pha.pa.us> Comments: In-reply-to Bruce Momjian message dated "Thu, 03 Oct 2002 18:15:59 -0400" Date: Thu, 03 Oct 2002 19:09:33 -0400 Message-ID: <15244.1033686573@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200210/177 X-Sequence-Number: 29946 Bruce Momjian writes: > So, in summary, reasons for the change: > more intuitive > more standard-compliant > more closely matches other db's I'd give you the first and third of those. As Andrew noted, the argument that "it's more standard-compliant" is not very solid. > Reasons not to change: > PostgreSQL traditional behavior You've phrased that in a way that makes it sound like the decision is a no-brainer. How about Breaks existing Postgres applications in non-obvious ways which I think is a more realistic description of the downside. Also, it seems a lot of people who have thought about this carefully think that the start-of-transaction behavior is just plain more useful. The fact that it surprises novices is not a reason why people who know the behavior shouldn't want it to work like it does. (The behavior of nextval/currval for sequences surprises novices, too, but I haven't heard anyone claim we should change it because of that.) So I think a fairer summary is Pro: more intuitive (but still not what an unversed person would expect, namely true current time) arguably more standard-compliant more closely matches other db's (but still not very closely) Con: breaks existing Postgres applications in non-obvious ways arguably less useful than our traditional behavior I've got no problem with the idea of adding a way to get at statement-arrival time. (I like the idea of a parameterized version of now() to provide a consistent interface to all three functionalities.) But I'm less than enthused about changing the existing functions to give pride of place to statement-arrival time. In the end, I think that transaction-start time is the most commonly useful and safest variant, and so I feel it ought to have pride of place as the easiest one to get at. regards, tom lane