pain of postgres upgrade with extensions

Поиск
Список
Период
Сортировка
От David Potts
Тема pain of postgres upgrade with extensions
Дата
Msg-id 1954.193.123.19.10.1205334521.squirrel@dp2642.force9.co.uk
обсуждение исходный текст
Ответы Re: pain of postgres upgrade with extensions  (paul rivers <rivers.paul@gmail.com>)
Re: pain of postgres upgrade with extensions  (dmp <danap@ttc-cmc.net>)
Список pgsql-general
This is not a flame about current or previous release of Postgres.

I have just gone through the awful experience of upgrading from Postgres
8.2 to 8.3 with a database that had one of the many Postgres extensions
included. The problem comes down to the way that Postgres extensions are
packaged up, each extension tends to define some extension specific
functions, when you do a dump of the database these functions get include.
 If upgrade from one version of Postgres to another, you take a dump of
the database, which then needs to be upgrade if there have been any
changes in the extension.  The problem being that there doesn’t seem
to be a way of dumping the database with out including extension specific
information.

There is a possible solution to this problem, move all the extension
specific functions to an extension specific schema.  That way the contents
of the database are kept separate from extensions.

For example the postgis function area would change to postgis.area
assuming the the schema for postgis extension was call postgis, this would
also avoid the problem if two extensions happen to have a function with
the same name.

D.

--
Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of the
Pinan Software



В списке pgsql-general по дате отправления:

Предыдущее
От: "Greg Sabino Mullane"
Дата:
Сообщение: Re: Trigger to run @ connection time?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ERROR: text search configuration "pg_catalog.english" does not exist