Re: Extensions versus pg_upgrade - Mailing list pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:
> I guess I'm sort of coming to the conclusion that ALTER EXTENSION ..
> UPGRADE is pretty much a must-have for a useful feature regardless of
> this issue.  I had previously thought that we might be able to limp
> along with half a feature for one release - if you're not actually
> depending on anything in the extension, you could always drop it and
> the install the new version.  But the more I think about it, the less
> realistic that sounds; dependencies on the extension are going to be
> very common, and while it may be practical to drop and recreate the
> dependent objects in some cases, it's certainly going to annoy a lot
> of people.

> So I think the choices, realistically, are boot both halves of this to
> 9.2, or do it all now.  I don't really have an opinion on which way to
> go with it.  We still have more than 40 patches to deal with for this
> CommitFest, and certainly booting this would free up a bunch of your
> time to go work on other things.  On the other hand, if you are fired
> up about getting this done, maybe it makes sense to get it knocked out
> while it's fresh in your mind instead of letting it linger for another
> six months.  It's clearly a good feature, and I know that Dimitri has
> put a lot of work into getting it this far.

Personally I find the extension stuff to be a bigger deal than anything
else remaining in the commitfest.  Also, I've fixed a number of
pre-existing bugs in passing, and I'd have to go extract those changes
out of the current extensions patch if we abandon it now.  So I'd like
to keep pushing ahead on this.

After further reflection I think that the pg_upgrade situation can be
handled like this:

1. Provide a way for CREATE EXTENSION to not run the script --- either
add a grammar option for that, or just have a back-door flag that
pg_upgrade can set via one of its special kluge functions.  (Hm,
actually we'd want it to install the old version number and comment
too, so maybe just have a kluge function to create a pg_extension
entry that agrees with the old entry.)

2. Invent a command "ALTER EXTENSION extname ADD object-description"
that simply adds a pg_depend entry marking an existing object as
belonging to the extension.  I think this was going to be part of the
plan anyway for ALTER EXTENSION UPGRADE, specifically we need that for
the bootstrap case of collecting some loose pre-existing objects into
an extension.

3. In --binary-upgrade mode, pg_dump doesn't suppress the individual
member objects, but instead emits ALTER EXTENSION ADD after creating
each member object.

So that gets us to the point of being able to run pg_upgrade without
changing the contents of the extension.  After that we can look at
ALTER EXTENSION UPGRADE.
        regards, tom lane