Extensions versus pg_upgrade - Mailing list pgsql-hackers

From Tom Lane
Subject Extensions versus pg_upgrade
Date
Msg-id 20783.1297184036@sss.pgh.pa.us
Whole thread Raw
Responses Re: Extensions versus pg_upgrade  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Re: Extensions versus pg_upgrade  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.

Now what?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql
Next
From: Robert Haas
Date:
Subject: Re: postponing some large patches to 9.2