Re: Very strange 'now' behaviour in nested triggers. - Mailing list pgsql-sql

From Denis Zaitsev
Subject Re: Very strange 'now' behaviour in nested triggers.
Date
Msg-id 20030727020104.A19865@natasha.ward.six
Whole thread Raw
In response to Very strange 'now' behaviour in nested triggers.  (Denis Zaitsev <zzz@anda.ru>)
Responses Re: Very strange 'now' behaviour in nested triggers.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-sql
On Sat, Jul 26, 2003 at 10:31:44AM -0400, Tom Lane wrote:
> Denis Zaitsev <zzz@anda.ru> 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?


pgsql-sql by date:

Previous
From: Denis Zaitsev
Date:
Subject: Re: Very strange 'now' behaviour in nested triggers.
Next
From: "Richard Huxton"
Date:
Subject: Re: Very strange 'now' behaviour in nested triggers.