On Sun, Aug 19, 2012 at 6:28 PM, Jeff Davis <pgsql@j-davis.com> wrote:
>> The other issue is how to handle multiple changes of the same record
>> within the transaction. Should they be stored or not?
>
> In a typical audit log, I don't see any reason to. The internals of a
> transaction should be implementation details; invisible to the outside,
> right?
I'm not convinced.
>> I'm not sure that the database user is the proper thing to be stored in
>> the history table. Many applications usually connect to a database using
>> some virtual user and have their own users/roles tables to handle with
>> privileges. There should be some way to substitute the stored user in
>> the history table with the application's one. It's also helpful to store
>> transaction id that inserted/updated/deleted the record.
>
> If the system is recording it for audit purposes, then it better be sure
> that it's true. You can't allow the application to pick and choose what
> gets stored there.
That position would render this feature useless for every application
for which I would otherwise have used it. I think it's just nonsense
to talk about what we can or can't let the user do. The user is in
charge, and our job is to allow him to do what he wants to do more
easily, not to dictate what he must do.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
