X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [64.117.224.130]) by svr1.postgresql.org (Postfix) with ESMTP id 7E70AD1C7F1 for ; Tue, 29 Jul 2003 22:07:38 +0000 (GMT) Received: from svr1.postgresql.org ([64.117.224.193]) by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024) with ESMTP id 00542-10 for ; Tue, 29 Jul 2003 19:06:40 -0300 (ADT) Received: from ward.six (unknown [212.57.173.234]) by svr1.postgresql.org (Postfix) with ESMTP id 60F0DD1C7F7 for ; Tue, 29 Jul 2003 19:07:34 -0300 (ADT) Date: Wed, 30 Jul 2003 04:05:14 +0600 From: Denis Zaitsev To: Tom Lane Cc: pgsql-sql@postgresql.org Subject: Re: Very strange 'now' behaviour in nested triggers. Message-ID: <20030730040514.C4870@natasha.ward.six> References: <20030726193947.B1636@natasha.ward.six> <9412.1059229904@sss.pgh.pa.us> <20030727020104.A19865@natasha.ward.six> <4629.1059320950@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4629.1059320950@sss.pgh.pa.us>; from tgl@sss.pgh.pa.us on Sun, Jul 27, 2003 at 11:49:10AM -0400 X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200307/436 X-Sequence-Number: 14550 On Sun, Jul 27, 2003 at 11:49:10AM -0400, Tom Lane wrote: > I put up a proposal in pgsql-hackers to change this behavior: > http://archives.postgresql.org/pgsql-hackers/2003-07/msg00818.php > If we made that change then the "wrong" way of defining the default > would fail in an obvious fashion --- the 'now' would get reduced to a > particular time immediately at CREATE TABLE. Doubtless this would annoy > some people, but the "right" way of defining the default isn't really > any harder, and it would save folks from getting burnt in corner cases, > like you were. > > Any comments? The proposed behavious promises to be "strict, simple and well-defined". The current one definitely tends to have "dirty and non-obvious side effects here and there". I think the new behaviour should conquer. BTW, the documentation describes this proposed behaviour (but why?), not the current one...