Thread: Upgrade extension from 8.4 to 9.1

Upgrade extension from 8.4 to 9.1

From
Alexander Rüegg
Date:
Hi,

sorry for posting this again, but my earlier questions did not appear in
the news server just on the webpage.

I am migrating databases from 8.4 to 9.1 using traditional backup and
restore. After restore to a clean database everything seems to be ok.
The only thing is that there are no extensions for my prior installed
modules. Do I really have to install extensions with "create extension
XXXXX from unpackaged"?
When I try to create the extension for "dblink" I get the following error:

ERROR: function dblink_get_notify() does not exist SQL Status:42883

In 8.4 I installed the module with the appropriate sql script in
share/contrib.
Now I ended up with uninstalling the module with the uninstall-script in
share/contrib and then creating the extension without "unpackaged". But
as we use PG in a product with a NSIS installer this makes the world
unnecessary complicated.

Thanks for your help in advance
Alex


Re: Upgrade extension from 8.4 to 9.1

From
Tom Lane
Date:
=?ISO-8859-15?Q?Alexander_R=FCegg?= <alr@bdal.de> writes:
> I am migrating databases from 8.4 to 9.1 using traditional backup and
> restore. After restore to a clean database everything seems to be ok.
> The only thing is that there are no extensions for my prior installed
> modules. Do I really have to install extensions with "create extension
> XXXXX from unpackaged"?

The "upgrade from unpackaged" scripts are designed to migrate from the
9.0 versions of the contrib modules.  If you try to use them on 8.4 or
older versions, it's not too surprising that there might be missing
functions and so on, meaning that this is not surprising:

> When I try to create the extension for "dblink" I get the following error:
> ERROR: function dblink_get_notify() does not exist SQL Status:42883

> Now I ended up with uninstalling the module with the uninstall-script in
> share/contrib and then creating the extension without "unpackaged".

That's what you're going to have to do.  It's no worse than what you'd
be doing if you needed to update to a newer version of the contrib
module in the pre-extensions world.  Take some comfort in the fact that
future upgrades will be smoother.

Now, if you have a large number of databases that you need to migrate,
you might consider building alternate upgrade scripts that can upgrade
directly from the 8.4 states of the contrib modules you're using.  The
extension mechanism is definitely capable of managing that, but nobody
bothered to do the legwork to create such scripts.

            regards, tom lane