Re: Statement level trigger clarification

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Chris Velevitch <chris(dot)velevitch(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Statement level trigger clarification
Date: 2008-09-18 04:51:30
Message-ID: 48D1DE52.2050900@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Peter Eisentraut wrote:
> Chris Velevitch wrote:

>> I have a function that sets new.last_modified := current_timestamp;

Remember that current_timestamp is stable across the lifetime of a
transaction; it'll return the same value each time it is called. Given
that, you can just use it in a row-level trigger, knowing that a batch
of records updated by the same transaction (which to the database is "at
the same time") will get the same timestamp.

There are also time functions that return the real wall clock, and the
clock at the time of the start of the statement rather than the
transaction. See:

http://www.postgresql.org/docs/current/static/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT

You do still pay the overhead of invoking a PL/PgSQL trigger for each
record altered/inserted, but there doesn't seem to be much of a way
around that. It's an area where a `DEFAULT FORCE' qualifier would be
nice - something to ignore user-submitted input and overwrite it with
the default parameter, probably a function call. At present there's
nothing like that (as far as I know) so you need to use a row-level trigger.

--
Craig Ringer

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Pavel Stehule 2008-09-18 05:03:21 Re: Synchronize two similar tables: recursive triggers
Previous Message Craig Ringer 2008-09-18 04:41:43 Re: Trigger does not behave as expected