Robert Haas 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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 33 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedFeb 8, '11 at 4:54p
activeFeb 10, '11 at 4:59p
posts33
users5
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase