From: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
---|---|
To: | yudhi s <learnerdatabase99(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: question on audit columns |
Date: | 2024-11-14 16:32:15 |
Message-ID: | CAKAnmm+jC-a_z_UBC5bjw5=gGc4uf3CRvQ4EOgOhO0XOvt95og@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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 guaranteed to use the default values of
current_timestamp() and current_user. And a BEFORE UPDATE trigger ensures
it changes the other two fields via the trigger function only.
Cheers,
Greg
P.S. Also check out https://www.pgaudit.org/ (PGAudit) as an alternative
approach, which puts the information into your Postgres logs, rather than
in the tables themselves.
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2024-11-14 16:45:25 | Re: postgresql-17.0-1 Application - silent installation Issue |
Previous Message | Ron Johnson | 2024-11-14 15:38:56 | Re: Help with restoring database from old version of PostgreSQL |