On 2/14/15 9:34 PM, David Steele wrote:
> The patch I've attached satisfies the requirements that I've had from
> customers in the past.
What I'm missing is a more precise description/documentation of what
those requirements might be.
"Audit" is a "big word". It might imply regulatory or standards
compliance on some level. We already have ways to log everything. If
customers want "auditing" instead, they will hopefully have a precise
requirements set, and we need a way to map that to a system
configuration. I don't think "we need auditing" -> "oh there's this
pg_audit thing, and it has a bunch of settings you can play with" is
going to be enough of a workflow. For starters, I would consider the
textual server log to be potentially lossy in many circumstances, so
there would need to be additional information on how to configure that
to be robust.
(Also, more accurately, this is an "audit trail", not an "audit". An
audit is an examination of a system, not a record of interactions with a
system. An audit trail might be useful for an audit.)
I see value in what you call object auditing, which is something you
can't easily do at the moment. But what you call session auditing seems
hardly distinct from statement logging. If we enhance log_statements a
little bit, there will not be a need for an extra module to do almost
the same thing.