* 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 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.
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
Idon't believe this will ever be the case while pgaudit exists as an extension- see below).
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.
Hope that helps.
Thanks,
Stephen
