Alvaro, * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > 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. > > I think you're making too much of this upgrade issue. Consider > autovacuum's history: in its initial form, we made it configurable per > table by asking users to insret rows in the pg_autovacuum catalog. It > was a pretty horrible user interface, it was very error prone, it didn't > survive dump/restore cycles (And autovacuum was a core feature, not an > extension).
I'm amazed that we didn't support those with dump/restore.. I'd be very
surprised if we were to accept that today.
> We were able to iron out a lot of issues during those
> initial two releases with the accumulated experience. We eventually
> replaced the interface with reloptions (ALTER TABLE SET), which is what
> we have today.
> We didn't add pg_upgrade code to migrate settings from
> the old way to the new one; users who wished to do this were responsible
> for handling it for themselves.
We didn't have pg_upgrade then though, so I'm not sure that this is
really relevant..? We've now committed to supporting pg_upgrade. In
any case, I'm not trying to simply throw up roadblocks or come up with
unlikely scenarios- I'm looking at the existing example in hstore and
considering how that's a contrib-to-core migration which has never been
able to happen, and my recollection is that the reasons have largely
been technical migration/upgrade issues.
> Sure, we're a more mature project now and our standards are higher. So
> I think we should provide documented procedures to upgrade from pgaudit
> to integrated feature; but that should suffice.
I have a very hard time believing that this would be acceptable.. If it
is, and we're all willing to agree that it's acceptable to break an
existing installation where the user runs 'pg_upgrade' and has pgaudit
installed (but they didn't follow the prescribed procedures), then I'd
like to understand why we're not alright with doing that for hstore..
(If we are- then I'd like to propose that we move hstore into core..)
> > 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 we can just ask users to run commands X, Y, Z to migrate their old
> configuration to the new integrated thing. No need for pg_upgrade
> procedures.
See above.
> > 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 pgaudit goes away, having fulfilled its mission in life which was to
> serve as audit mechanism for the older releases.
I'd be fine with that. I'll note that it doesn't make any sense to add
pgaudit to contrib if it's goal is to handle older-than-current (9.4)
releases, but I'm guessing you mean "prior-to-10.1", per my scenario.
> > 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 don't fear this will happen, either, so why mention it?
Because I'm concerned it will?
Thanks,
Stephen
signature.asc
Description: Digital signature
