Stephen Frost wrote: > * 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 as we'd then have to figure out how to make pg_upgrade deal with > moving such a configuration from the extension's table or from > reloptions into SQL commands which work against the version of PG which > implements the capability in core.
I think you're making too much of this upgrade issue. Consider autovacuum's history: in its initial form, we made it configurable per table by asking users to insret rows in the pg_autovacuum catalog. It was a pretty horrible user interface, it was very error prone, it didn't survive dump/restore cycles (And autovacuum was a core feature, not an extension). We were able to iron out a lot of issues during those initial two releases with the accumulated experience. We eventually replaced the interface with reloptions (ALTER TABLE SET), which is what we have today. We didn't add pg_upgrade code to migrate settings from the old way to the new one; users who wished to do this were responsible for handling it for themselves. Sure, we're a more mature project now and our standards are higher. So I think we should provide documented procedures to upgrade from pgaudit to integrated feature; but that should suffice. > My concern is: > > pg_upgrade then has to detect, understand, and implement a migration > path from 10.0-with-pgaudit to 10.1-in-core-auditing. Or we can just ask users to run commands X, Y, Z to migrate their old configuration to the new integrated thing. No need for pg_upgrade procedures. > The PG 10.1 patch has to ensure that it doesn't break, harm, or > interfere with what pgaudit is doing in its per-role auditing. Or pgaudit goes away, having fulfilled its mission in life which was to serve as audit mechanism for the older releases. > The PG 10.1 patch is bounced because what pgaudit does is considered > "good enough" and it's already in contrib (though I don't believe this > will ever be the case while pgaudit exists as an extension- see > below). I don't fear this will happen, either, so why mention it? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
