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

From Tom Lane
Subject Re: Very strange 'now' behaviour in nested triggers.
Date
Msg-id 9412.1059229904@sss.pgh.pa.us
Whole thread Raw
In response to Very strange 'now' behaviour in nested triggers.  (Denis Zaitsev <zzz@anda.ru>)
List pgsql-sql
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:

regression=# insert into xxx values('a');
INSERT 154541 1
regression=# insert into xxx values('b');
INSERT 154542 1
regression=# prepare s(text) as insert into xxx values($1);
PREPARE
regression=# execute s('q1');
EXECUTE
regression=# execute s('q2');
EXECUTE
regression=# select * from xxx;s  |             t
----+----------------------------a  | 2003-07-26 10:18:51.364913b  | 2003-07-26 10:18:53.519648q1 | 2003-07-26
10:19:21.795415q2| 2003-07-26 10:19:21.795415
 
(4 rows)

The default would work the way you want with almost any other way of
doing it.  For instance
default now()default current_timestampdefault localtimestampdefault 'now'::text

Given that you want timestamp without time zone, I'd probably use
"default localtimestamp".
        regards, tom lane


pgsql-sql by date:

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