On Tue, Feb 8, 2011 at 11:53 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
