[Dbconfig-common-devel] dbconfig-common/doc dbapp-policy.html,1.5,1.6 dbconfig-common-design.html,1.4,1.5 dbconfig-common-using.html,1.5,1.6 dbconfig-common.html,1.5,1.6

[Karsten Hilbert]

> > >  the backup should be performed early, ahead of
> > > -the new package being unpacked.  this ensures that the versions of the
> > > -software necessary to interact with the previous version of the database
> > > -are present, since newer versions of the tools might not necessarily
> > > -be compatible.
> > In PostgreSQL the recommended procedure is to use the pg_dump
> > of the *newer* version, however.
> 
> > Taken together this probably means that one should
> > 
> > a) make a backup with the old version before changing anything
> >    just to be on the safe side
> > b) make a second backup intended for restoring into the new
> >    database version as soon as the new dump utility is
> >    available
> 
> hmm.. i might have to defer to someone who knows the idiosynchrasies of
> postgres better than myself on this.
It should surely *work* using the "old" pg_dump. But it's
recommended to use the new one due to bugs having been fixed.

An example:

Pre-8.0 pg_dump would produce technically proper database
dumps. They would not, however, in many cases deal with
inter-object dependancies properly. In other words the dump
was there but would not restore with some manual intervention
(re-ordering of table ordering). Later versions do know how to
properly order things to make the dump restore even in the
face of dependancies. Lest I be mistaken they now even know
how to deal with cyclic dependancies.

> is there anything that would be
> different in the SQL between versions?
Not as regards the basic stuff. Some dependancy-resolution code
might require ALTER TABLE statements that are not available yet
in earlier versions.

>  my approach thusfar was to
> avoid the binary dump formats of mysql/pgsql in favor of the plain old SQL 
> format to try and circumvent such problems.
Sure, that's being on the safe side. Still, see above :-)

> glad to see there are still folks interested in this :)
Having a working framework for this is a huge gain !

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346