All, * Robert Haas (robertmh...@gmail.com) wrote: > OK, I'll bite: I'm worried that this patch will be a maintenance > burden. It's easy to imagine that changes to core will result in the > necessity or at least desirability of changes to pgaudit, but I'm > definitely not prepared to insist that future authors try to insist > that future patch submitters have to understand this code and update > it as things change.
I agree with this concern in general, and have since pgaudit was first proposed for inclusion by Simon two years ago. Having auditing as an extension is what makes this into an issue though. Were auditing baked into core, it'd be far more straight-forward, much easier to maintain, and would be updated as we add new core capabilities naturally. David's comments about how pgaudit has to work are entirely accurate- everything ends up having to be reconstructed in a very painful way. > The set of things that the patch can audit is pretty arbitrary and not > well tied into the core code. This also speaks to the difficulties of having auditing implemented as an extension. * Tom Lane (t...@sss.pgh.pa.us) wrote: > Yeah. Auditing strikes me as a fine example of something for which there > is no *technical* reason to need to put it in core. It might need some > more hooks than we have now, but that's no big deal. I disagree with this, quite strongly. There are very good, technical, reasons why auditing should be a core capability. Adding more hooks, exposing various internal functions for use by extensions, etc, doesn't change that any extension would have to be constantly updated as new capabilities are added to core and auditing, as a capability, would continue to be limited by virtue of being implemented as an extension. I don't mean to detract anything from what 2ndQ and David have done with pgaudit (which is the only auditing solution of its kind that I'm aware of, so I don't understand the "competing implementations" argument which has been brought up at all- there's really only one). They've done just as much as each version of PG has allowed them to do. It's a much better solution than what we have today (which is basically just log_statement = 'all', which no one should ever consider to be a real auditing solution). I've already stated that I'd be willing to take on resonsibility for maintaining it as an extension (included with PG or not), but it's not the end-all, be-all of auditing for PG and we should be continuing to look at implementing a full in-core auditing solution. I'm still of the opinion that we should include pgaudit for the reason that it's a good incremental step towards proper in-core auditing, but there's clearly no consensus on that and doesn't appear that further discussion is likely to change that. An in-core auditing solution would provide us with proper grammar support, ability to directly mark objects for auditing in the catalog, allow us to much more easily maintain auditing capability over time as a small incremental bit of work for each new feature (with proper in-core infrastructure for it) and generally be a far better technical solution. Leveraging the GRANT system is quite cute, and does work, but it's certainly non-intuitive and is only because we've got no better way, due to it being implemented as an extension. Looking at pgaudit and the other approaches to auditing which have been developed (eg: applications which sit in front of PG and essentially have to reimplement large bits of PG to then audit the commands sent before passing them to PG, or hacks which try to make sense out of log files full of SQL statements) make it quite clear, in my view, that attempts to bolt-on auditing to PG result in a poorer solution, from a technical perspective, than what this project is known for and capable of. To make true progress towards that, however, we need to get past the thinking that auditing doesn't need to be in-core or that it should be a second-class citizen feature or that we don't need it in PG. Thanks! Stephen
signature.asc
Description: Digital signature
