Re: Trigger usecase

Adrian Klaver <adrian.klaver@aklaver.com>

From: Adrian Klaver <adrian.klaver@aklaver.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>, sud <suds1434@gmail.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, pgsql-general <pgsql-general@lists.postgresql.org>
Date: 2024-07-30T21:11:28Z
Lists: pgsql-general
On 7/30/24 13:28, David G. Johnston wrote:
> On Tue, Jul 30, 2024 at 11:46 AM sud <suds1434@gmail.com 
> <mailto:suds1434@gmail.com>> wrote:
> 
> 
>     Not sure of the exact pros and cons, but we were following certain
>     rules like , if it's business logic which needs to be implemented in
>     Database, then it should not be done using triggers but rather
>     should be done through database procedure/functions. Hope this
>     understanding correct.
> 
> 
> That is my personal take.  For process-oriented stuff you can follow the 
> trail of calls all the way through to the end of the process and its 
> final result.  With triggers you follow the trail to the 
> insert/update/delete then stop thinking that's it, while in reality it 
> continues because you have triggers performing yet more work.
> 

"On insert/update/delete to this table the following actions are taken 
via triggers using the supplied function/procedure:

Insert
     Data is sent to audit table using table_audit()
Update
     Data is sent to audit table using table_audit()
Delete
     Data is sent to audit table using table_audit()

See function specific documentation below

[...]
"
> David J.
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com