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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +