Hi ,
https://wiki.postgresql.org/wiki/Audit_trigger_91plus OR
https://wiki.postgresql.org/wiki/Audit_trigger
Although there are documented limitations for these systems , but
I would like to mention and seek suggestion on a limitation that I feel is biggest .
It is very a common design pattern in web-applications that the same database
user is shared for making database changes by different "logged in users" of the
web application.
web application.
I feel the core of audit is all about "who" , "when" and "what" .
In the current audit trigger the "who" is essentially the ROLE which is the actor of
the trigger , but in most scenarios the user associated with the web-application session
is the one that is seeked.
the trigger , but in most scenarios the user associated with the web-application session
is the one that is seeked.
In one of my past projects I passed the web-user to the trigger by setting a postgres
custom variable during the database connection and reading it inside the trigger
custom variable during the database connection and reading it inside the trigger
and storing it in the audit log table.
I am curious how others deal with the same issue , is there better or more inbuilt solutions
to store the application level user in the audit trail records.
Regds
mallah.
