* 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.
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
