As far as the application being able to change those fields itself, you can
prevent that via column permissions, by leaving out the four audit columns
and doing something like:
GRANT INSERT (email, widget_count), UPDATE (email, widget_count) ON TABLE
foobar TO PUBLIC;
That way, inserts are guaran
... and (3) the values are not updated on manual actions without
triggers - which might or might not be desirable depending on the intention.
Best,
Johannes
On 9/4/2024 16:36, Adrian Klaver wrote:
On 9/4/24 06:17, Khan Muhammad Usman wrote:
Yes this would be the better approach.
1) Except
On Wed, 4 Sep 2024 18:19:47 +0530
yudhi s wrote:
Hi,
> In postgres database , we have all the tables with audit columns like
> created_by_user, created_timestamp,updated_by_user, updated_timestamp. So
> we have these fields that were supposed to be populated by the time at
> which the insert/upd
>
> On 9/4/24 06:17, Khan Muhammad Usman wrote:
> > Yes this would be the better approach.
>
> 1) Except the overhead is now shifted to the application, which may or
> not be better. You are also moving the audit responsibility to the
> application and the application maintainers and making it appl
On 9/4/24 06:17, Khan Muhammad Usman wrote:
Yes this would be the better approach.
1) Except the overhead is now shifted to the application, which may or
not be better. You are also moving the audit responsibility to the
application and the application maintainers and making it application
s
On Wed, Sep 4, 2024 at 9:10 AM yudhi s wrote:
>
> On Wed, Sep 4, 2024 at 6:29 PM Muhammad Usman Khan
> wrote:
>
>> Hi,
>>
>> In your scenario, triggers can add some overhead since they require extra
>> processing after each update operation. Considering the size of your table
>> and the high tra
Yes this would be the better approach.
Sent from Outlook for Android<https://aka.ms/AAb9ysg>
From: yudhi s
Sent: Wednesday, September 4, 2024 6:10:04 PM
To: Muhammad Usman Khan
Cc: pgsql-general
Subject: Re: question on audit columns
On Wed, Sep 4, 202
On Wed, Sep 4, 2024 at 6:29 PM Muhammad Usman Khan
wrote:
> Hi,
>
> In your scenario, triggers can add some overhead since they require extra
> processing after each update operation. Considering the size of your table
> and the high transaction volume, you need to observe that this might
> signi
Hi,
In your scenario, triggers can add some overhead since they require extra
processing after each update operation. Considering the size of your table
and the high transaction volume, you need to observe that this might
significantly affect performance.
On Wed, 4 Sept 2024 at 17:50, yudhi s
