@postgresql.org
Subject: Re: [GENERAL] pain of postgres upgrade with extensions
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
- dump version N database
- create empty version N+1 database
- install N+1's version of each needed contrib module into new database
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,
David Potts wrote:
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
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
paul rivers [EMAIL PROTECTED] writes:
Is this something that wouldn't be fixed by:
- dump 8.2 database
- load dump into 8.3 database
- for each extension, run the 8.2 drop extension script in 8.2's contrib
- for each extension, run the 8.3 install extension script in 8.3's contrib
The
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
- dump version N database
- create empty version N+1 database
- install N+1's version of each needed contrib module into new database
- restore dump, ignoring object already exists errors
There is a TODO to
On Wed, Mar 12, 2008 at 07:34:03PM -, Greg Sabino Mullane wrote:
- dump version N database
- create empty version N+1 database
- install N+1's version of each needed contrib module into new database
- restore dump, ignoring object already exists errors
There is a TODO to figure out
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
- dump version N database
- create empty version N+1 database
- install N+1's version of each needed contrib module into new database
- restore dump, ignoring object already exists errors
There is a TODO to figure out some cleaner way of
On Mar 12, 2008, at 3:19 PM, Tom Lane wrote:
- restore dump, ignoring object already exists errors
Couldn't one use the dump listing feature of pg_restore and comment
out the extensions when restoring? Not likely to be a big improvement
over ignore errors :-)
--
Sent via
