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