Re: Extensions versus pg_upgrade - Mailing list pgsql-hackers

On Tue, Feb 8, 2011 at 11:53 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> It just occurred to me that the extensions patch thoroughly breaks
> pg_upgrade, because pg_upgrade imagines that it can control the specific
> OIDs assigned to certain SQL objects such as data types.  That is of
> course not gonna happen for objects within an extension.  In fact, since
> part of the point of an extension is that the set of objects it packages
> might change across versions, it wouldn't be sensible to try to force
> OID assignments even if there were a practical way to do it.
>
> Offhand the only escape route that I can see is for a binary upgrade to
> not try to install a newer version of an extension, but just duplicate
> all the contained objects exactly.  Which is probably less than trivial
> to do --- we could get part of the way there by having pg_dump not
> suppress the member objects in --binary-upgrade mode, but then we need
> some awful kluge to re-establish their pg_depend links to the extension.
> In any case that would ratchet the priority of ALTER EXTENSION UPGRADE
> back up to a must-have-for-9.1, since pg_upgrade would then leave you
> with a non-upgraded extension.

If we're going to commit any part of this for 9.1, it doesn't seem
like there's much choice but to insert the above-mentioned awful
kludge.  It's certainly not going to work if we fail to preserve the
OIDs in cases where pg_upgrade otherwise thinks it's necessary.

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company