* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@snowman.net> writes: > > * Bruce Momjian (br...@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. Still, if we're fine with perl scripts and similar hacks to facilitate upgrading from pgaudit to an in-core solution, then I won't object to including pgaudit until we've got that in-core capability. > If the concern is that the required metadata is going to change over time, > I'd suggest that maybe an extension is the right place for it, > permanently. We have some infrastructure for extension version upgrades, > which could cope with metadata changes. There's not nearly as much > provision for changes of core state. I don't follow this at all- we already deal with changes in core between major versions via pg_dump/pg_upgrade and I have every expectation that we'll continue to lean on that into the future. Thanks, Stephen
Description: Digital signature