Well, upon further reflection, I came to this conclusion:
In order to do trigger-based auditing that logs a homegrown user, you
need to hand the database some token or identifier for the user that it
can use to record the user into the audit log. That part is pretty
straightforward: if you're n
Hi Ian,
Thanks for the quick reply. What I'm confused about is how I let
the trigger function etc. know which homegrown user it was that touched
the record. Any advice?
Thanks,
Eric
Ian Harding wrote:
I have a homegrown userid/password system in a database table, and on
tables I audit, I ke
I have a homegrown userid/password system in a database table, and on
tables I audit, I keep the id of the last person to touch that record,
and have a trigger write the changed values out to an audit table. It
works fine, but of course there is some overhead involved.
You can't involve postgres
Hi all,
Like many folks who use three-tier design, I would like to create an
audit trail in my Postgres database, and I would like to do so without
having to create a database user for each audit.
As I see it, there are two ways to do this, and I can't see a clear way
to do either of them.
