Re: naming triggers for execution

2019-11-15 Thread Adrian Klaver
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

Re: naming triggers for execution

2019-11-15 Thread PegoraroF10
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

Re: naming triggers for execution

2019-11-15 Thread PegoraroF10
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

Re: naming triggers for execution

2019-11-15 Thread srkrishna
> 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

Re: naming triggers for execution

2019-11-15 Thread Michael Nolan
> 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