Re: pgaudit - an auditing extension for PostgreSQL

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