Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id DB11F475DA7 for ; Tue, 24 Sep 2002 11:19:46 -0400 (EDT) Received: from ece.rice.edu (ece.rice.edu [128.42.4.34]) by postgresql.org (Postfix) with ESMTP id 78160475CB1 for ; Tue, 24 Sep 2002 11:19:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ece.rice.edu (Postfix) with ESMTP id E87E068AD3; Tue, 24 Sep 2002 10:19:50 -0500 (CDT) Received: from wallace.ece.rice.edu (wallace.ece.rice.edu [128.42.12.154]) by ece.rice.edu (Postfix) with ESMTP id 92D6A68AD1; Tue, 24 Sep 2002 10:19:49 -0500 (CDT) Received: from reedstrm by wallace.ece.rice.edu with local (Exim 3.34 #1 (Debian)) id 17trTZ-000240-00; Tue, 24 Sep 2002 10:19:49 -0500 Date: Tue, 24 Sep 2002 10:19:49 -0500 From: "Ross J. Reedstrom" To: Josh Berkus Cc: Tom Lane , Manfred Koizar , Bruce Momjian , Aaron Held , Roberto Mello , Neil Conway , pgsql-sql@postgresql.org Subject: Re: [GENERAL] CURRENT_TIMESTAMP Message-ID: <20020924151949.GD7612@rice.edu> Mail-Followup-To: "Ross J. Reedstrom" , Josh Berkus , Tom Lane , Manfred Koizar , Bruce Momjian , Aaron Held , Roberto Mello , Neil Conway , pgsql-sql@postgresql.org References: <12393.1032873985@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Virus-Scanned: by AMaViS snapshot-20020300 X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200209/306 X-Sequence-Number: 9583 On Tue, Sep 24, 2002 at 08:05:59AM -0700, Josh Berkus wrote: > > This looks fine to me, as a search-and-replace on current_timestamp is > easy. However, we need to do a better job of warning people about the > change than we did with interval() to "interval"(). > > Actually, can I make the proposal that *any* change that breaks > backward compatibility be mentioned in both the new version > announcement and on the download page? This would prevent a lot of > grief. If I'm kept informed of these changes, I'll be happy to write > up a user-friendly announcement/instructions on how to cope with the > change. I'd suggest we (for values of we that probably resolve to Bruce or a Bruce triggered Josh ;-) start a new doc, right now, for 7.4_USER_VISIBLE_CHANGES, or some other, catchy title. In it, document, with example SQL snippets, if need be, the change from previous behavior, _when the patch is committed_. In fact, y'all could be hardnosed about not accepting a user visible syntax changing patch without it touching this file. Such a document would be invaluable for database migration. On another note, this discussion is happening on GENERAL and SQL, but is getting pretty technical - should someone more it to HACKERS to get input from developers who don't hang out here? Ross