On 11/15/2012 03:32 PM, Stuart Bishop wrote: >> That's a known issue with several of the extensions. You need to upgrade >> the contrib module install to the current version, *then* wrap the >> unpackaged contrib module into an extension with "FROM UNPACKAGED". > Yeah, just thought I'd stick it in the... umm... bugtracker, as so far > 'FROM unpackaged' has failed in 66% of up updates. Is the real > solution is for the foo--unpackaged--1.0.sql script to recreate > missing objects before adding them to the extension? For simple extensions running the create script should do the job, yes. It's not so clear cut for extensions that define data types, though.
If I recall correctly the general advice for those has been to: - Create the new versions of extensions in the DB you're going to restore to; then - restore your database to that DB with the extensions pre-created in it. I'm surprised not to find any documentation on coping with this issue in: http://www.postgresql.org/docs/current/static/contrib.html <http://www.postgresql.org/docs/9.2/static/contrib.html> or http://www.postgresql.org/docs/current/static/extend-extensions.html <http://www.postgresql.org/docs/9.2/static/extend-extensions.html> (though it's possible it's there and I missed it). There used to be brief mention in contrib.html before the extensions changes went in, saying: "After a major-version upgrade of PostgreSQL, run the installation script again, even though the module's objects might have been brought forward from the old installation by dump and restore. This ensures that any new functions will be available and any needed corrections will be applied." ... but I'm not certain that advice is sufficient for all contrib modules. Extensions were created because upgrading DBs that used contrib modules was a painful mess. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
