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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers