From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, sud <suds1434(at)gmail(dot)com> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Trigger usecase |
Date: | 2024-07-30 21:11:28 |
Message-ID: | b4deb9ae-9817-497d-b33e-3967b6d5f78c@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 7/30/24 13:28, David G. Johnston wrote:
> On Tue, Jul 30, 2024 at 11:46 AM sud <suds1434(at)gmail(dot)com
> <mailto:suds1434(at)gmail(dot)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(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Koen De Groote | 2024-07-30 23:22:45 | Re: Understanding conflicts on publications and subscriptions |
Previous Message | David G. Johnston | 2024-07-30 20:28:35 | Re: Trigger usecase |