Re: Auditing extension for PostgreSQL (Take 2)

On 5/7/15 8:26 AM, Stephen Frost wrote:
> * Peter Eisentraut (peter_e(at)gmx(dot)net) wrote:
>> On 5/4/15 8:37 PM, Stephen Frost wrote:
>>> I don't follow this logic. The concerns raised above are about changing
>>> our in-core logging. We haven't got in-core auditing and so I don't see
>>> how they apply to it.
>>
>> How is session "auditing" substantially different from statement logging?
>
> David had previously outlined the technical differences between the
> statement logging we have today and what pgAudit does, but I gather
> you're asking about it definitionally, though it ends up amounting to
> much the same to me. Auditing is about "what happened" whereas
> statement logging is "log whatever statement the user sent." pgAudit
> bears this out by logging internal SQL statements and object
> information, unlike what we do with statement logging today.

That's a great way to describe it and I'll see if I can incorporate this
idea into the docs to hopefully make the topic a bit clearer.

>> I think it is not, and we could tweak the logging facilities a bit to
>> satisfy the audit trail case while making often-requested enhancement to
>> the traditional logging use case as well at the same time.
>
> Changing our existing statement logging to be a "what happened" auditing
> system is possible, but I don't see it as a "tweak."

Agreed - not the least of which would be figuring out a more detailed
statement classification system for core which would probably be the
first step.

> Lastly, from the perspective of the session logging piece, the code
> footprint for that in pgAudit isn't the bulk or even terribly
> significant, most of the code would still be required for the object
> auditing capability.

Both have a decent footprint but also a lot in common so it's fair to
say that removing session audit logging would not reduce the amount of
code significantly.

--
- David Steele
david(at)pgmasters(dot)net