Re: pgaudit - an auditing extension for PostgreSQL

On 31 July 2014 22:34, Stephen Frost <sfrost@snowman.net> wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> Stephen Frost <sfrost@snowman.net> writes:
>> > * Bruce Momjian (bruce@momjian.us) wrote:
>> >> Actually, thinking more, Stephen Frost mentioned that the auditing
>> >> system has to modify database _state_, and dumping/restoring the state
>> >> of an extension might be tricky.
>>
>> > This is really true of any extension which wants to attach information
>> > or track things associated with roles or other database objects.  What
>> > I'd like to avoid is having an extension which does so through an extra
>> > table or through reloptions or one of the other approaches which exists
>> > in contrib and which implements a capability we're looking at adding to
>> > core
>>
>> We have core code that uses reloptions --- autovacuum for instance ---
>> so I'm not exactly clear on why that's so unacceptable for this.
>
> There was a pretty good thread regarding reloptions and making it so
> extensions could use them which seemed to end up with a proposal to turn
> 'security labels' into a more generic metadata capability.  Using that
> kind of a mechanism would at least address one of my concerns about
> using reloptions (specifically that they're specific to relations and
> don't account for the other objects in the system).  Unfortunately, the
> flexibility desired for auditing is more than just "all actions of this
> role" or "all actions on this table" but also "actions of this role on
> this table", which doesn't fit as well.

Yes, there is a requirement, in some cases, for per role/relation
metadata. Grant and ACLs are a good example.

I spoke with Robert about a year ago that the patch he was most proud
of was the reloptions abstraction. Whatever we do in the future,
keeping metadata in a slightly more abstract form is very useful.

I hope we can get pgAudit in as a module for 9.5. I also hope that it
will stimulate the requirements/funding of further work in this area,
rather than squash it. My feeling is we have more examples of feature
sets that grow over time (replication, view handling, hstore/JSONB
etc) than we have examples of things languishing in need of attention
(partitioning).

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services