On 11/15/19 7:11 AM, PegoraroF10 wrote:
well, my way of doing auditing is done on replica, so it´s a little different
on production server I do on before update
IF (tg_op = 'UPDATE') AND (new.* IS DISTINCT FROM old.*) THEN
new.userauditing = User_ID
new.datetimeauditing = current_ti
I know it´s possible, but it´s ugly.
When you see a trigger called zaudittable is really strange
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
well, my way of doing auditing is done on replica, so it´s a little different
on production server I do on before update
IF (tg_op = 'UPDATE') AND (new.* IS DISTINCT FROM old.*) THEN
new.userauditing = User_ID
new.datetimeauditing = current_timestamp;
END IF;
RETURN new;
Then, on re
> But suppose we have two triggers, one is called for every table for auditing
> purposes, for example. And other for a specific process of that table.
> Considering that the auditing needs to be the last, how can I be sure it´ll
> ran lastly ?
May be I am not getting the full picture. Why
> Considering that the auditing needs to be the last, how can I be sure it´ll
> ran lastly ?
>
IMHO, auditing should be done in after- triggers, when that the data in the
records being inserted, updated or deleted can't be changed but you can
still write to the separate auditing tables.
--
Mike No
On create trigger page of the doc:
If multiple triggers of the same kind are defined for the same event, they
will be fired in alphabetical order by name.
But suppose we have two triggers, one is called for every table for auditing
purposes, for example. And other for a specific process of that tab
