Re: Very strange 'now' behaviour in nested triggers.
От | Tom Lane |
---|---|
Тема | Re: Very strange 'now' behaviour in nested triggers. |
Дата | |
Msg-id | 9412.1059229904@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Very strange 'now' behaviour in nested triggers. (Denis Zaitsev <zzz@anda.ru>) |
Список | 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 по дате отправления: