Re: pain of postgres upgrade with extensions

Поиск
Список
Период
Сортировка
От dmp
Тема Re: pain of postgres upgrade with extensions
Дата
Msg-id 47D80698.3050407@ttc-cmc.net
обсуждение исходный текст
Ответ на pain of postgres upgrade with extensions  ("David Potts" <dave.potts@pinan.co.uk>)
Список pgsql-general
I noticed this immediately when using the PostgreSQL tool for examples of
dumps for creating export of database/table structure/data for the
MyJSQLView
application. I considered implementing a similar copy dump, but seems it
would
not be handled properly with SQL statements.
danap.


>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.
>

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

Предыдущее
От: paul rivers
Дата:
Сообщение: Re: pain of postgres upgrade with extensions
Следующее
От: "jose javier parra sanchez"
Дата:
Сообщение: Re: postgre vs MySQL