* Bruce Momjian (bruce@momjian.us) wrote:
> I think someone could write a Perl script that you run before the
> upgrade to create SQL commands to restore the audit settings.
Is pg_upgrade going to detect that pgaudit is installed and know to run
this perl script? I don't doubt that it'd be possible to have such a
script, but there's an open question (in my mind anyway..) as to exactly
what would be acceptable to the community for such a migration.
What I wish to avoid is the situation which exists around hstore.
Perhaps I've got this wrong, but my recollection of the discussion
leads me to believe that we can't have hstore in core becasue there's
no simple migration path from an hstore-enabled installation to one
where hstore is in core instead. I'm not sure that a perl script would
be sufficient in that case (the issue involves the remapping of the OIDs
for the functions and operators installed, no?), but if it was, would
that be an acceptable way to deal with the issues?
> That is the larger issue --- I can't think of any extension that has to
> store state like that.
There's quite a few which would *like* to store such state and we see
requests regularly to use reloptions or similar to do so, but that's
really not a good solution as there isn't any way to prevent conflicts
or to have much more than simple tags. Fixing that has been discussed
also, but it's more than just a namespace issue- we'd also need to
provide a way to call into the extension when changes are made, and we'd
need to provide a similar capability for all of the objects which we
manage in the catalog. Implemneting this for just tables or just roles
or, worse, implementing it in a different way for each and every object
type we have, would really make it painful to write extensions which use
that facility.
Thanks,
Stephen
