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 B58ECD1C92B for ; Sat, 26 Jul 2003 20:03:52 +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 57088-07 for ; Sat, 26 Jul 2003 17:03:02 -0300 (ADT) Received: from ward.six (unknown [212.57.173.222]) by svr1.postgresql.org (Postfix) with ESMTP id BEC23D1C927 for ; Sat, 26 Jul 2003 17:03:49 -0300 (ADT) Date: Sun, 27 Jul 2003 02:01:04 +0600 From: Denis Zaitsev To: pgsql-sql@postgresql.org Subject: Re: Very strange 'now' behaviour in nested triggers. Message-ID: <20030727020104.A19865@natasha.ward.six> References: <20030726193947.B1636@natasha.ward.six> <9412.1059229904@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200307/399 X-Sequence-Number: 14513 On Sat, Jul 26, 2003 at 10:31:44AM -0400, Tom Lane wrote: > Denis Zaitsev writes: > > create table xxx ( > > s text, > > t timestamp > > default 'now' > > ); > > That's a dangerous way to define the default --- 'now' is taken as a > literal of type timestamp, which means it will be reduced to a timestamp > constant as soon as a statement that requires the default is planned. > You lose in plpgsql because of plan caching, but you'd also lose if you > tried to PREPARE the insert command. Example: Aaa... So, the INSERT inside a trigger will use the 'now' for the time this trigger is compiled (i.e. called first time)? Do I understand right? And the only outer trigger uses the right 'now' as its value goes from the top-level INSERT... Thank you very much. By the way, do you think this method with nested triggers has some 'moral weakness' vs. just cycling left-to-right on the comma-separated string in the 'do instead' rule for some view of xxx?