On Fri, Feb 5, 2016 at 1:16 PM, Stephen Frost <sfr...@snowman.net> wrote: > 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.
Yeah, I agree. Let me clarify my position: I'm not opposed to in-core auditing. I'm also not in favor of it. If somebody makes a proposal in that area, I'll probably have an opinion on it, but until then I don't. What I'm opposed to is shipping this in core rather than letting it continue to exist outside core. I see no benefit to that and some possible downsides that I think justify rejecting it. Of course other people are entitled to their own opinions; what I'm saying is: that's my opinion. If somebody came along with a proposal to put auditing in core that offered the advantages you cite here, none of my objections to this would be objections to that. Would I have other objections? Maybe, but not necessarily. For example, one thing that occurs to me is that, at least in some cases, we've got a built-in way of finding out all of the objects that a query touches: the list of PlanInvalItems. Is it a clever idea to try to drive auditing off that list, or a terrible idea? I'm not sure, but clearly if it's a good idea that would make this largely self-maintaining, which IMHO completely changes the calculus about whether it's worth doing. Also, we've got quite a few ObjectAddress-related facilities in the core system now that know how to do various kinds of things with any sort of SQL-accessible object in the system. Leveraging that infrastructure seems like a big plus. I'd be much more likely to support a proposal that does this stuff in a generic way that touches every SQL object type, and contains little or no hard-wired information about particular SQL object types in the auditing code itself. I'm not blind to the fact that auditing relation access is more valuable than auditing text search parser access, but it's harder to predict what we might think about the next three SQL object types we add, and I don't want the burden to be on the people who add that stuff to teach auditing about it if somebody wants that. Rather, I think the auditing system should know about everything we've got, and which stuff actually gets audited should be a matter of configuration. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
