On Wed, Jul 30, 2014 at 02:29:47PM -0400, Stephen Frost wrote: > Using auditing as an example, consider this scenario: > > pgaudit grows a table which is used to say "only audit roles X, Y, Z" > (or specific tables, or connections from certain IPs, etc). > > A patch for PG 10.1 is proposed which adds the ability to enable > auditing for specific roles. > > 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 > > 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 > > 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 think someone could write a Perl script that you run before the upgrade to create SQL commands to restore the audit settings. > From my perspective, it's pretty clear that we don't have any good > way for any extension, today, to have metadata properly associated > with database objects- such that renames, upgrades, dependency > issues, etc, are properly addressed and handled; nor are extensions > able to extend the grammar; and there is a concern that extensions may > not always be properly loaded, a serious concern when the role of that > extension is auditing. That is the larger issue --- I can't think of any extension that has to store state like that. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
