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 по дате отправления: