On 5/7/15 8:26 AM, Stephen Frost wrote: > * Peter Eisentraut (pete...@gmx.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 da...@pgmasters.net
signature.asc
Description: OpenPGP digital signature
