Re: Calling all testers: 1.1 now in feature freeze

[David Tangye <..hidden..>]

On Mon, 2006-09-18 at 18:32 -0700, Chris Travers wrote:
> Hi all;
> 
> Here is the basic problem is that the program looks through the
> Pg-tables.sql and Pg-upgrade-*.sql for create table statements.  It
> then dumps these tables into insert statements.
If it builds insert statements from 'create table' statements then
backup does not backup truely the application's area of the database, so
is dangerous.

The only way I have ever written application backup code, is to have the
code look in the database for subject matter, not the create__.sql
scripts that *might* be the basis for the current schema. This way, if
anyone adds columns, eg as per your latest fix allows, or someone hacks
a change into anywhere in the schema, that change is preserved, not
lost. Backup should backup exactly what is there, no matter how it got
there.

pg_dump is the next level up isn't it? ie Its a DBMS level backup. Even
if it can back up per dataset, which fully contains an application's
data, its not quite the same thing.

> It would be a *lot* simpler to create this using pg_dump except that
> typical installations break this functionality.  Pg_dump dumps the
> database relative to template0, so if you create the plpgsql in
> template1, it will create this language as well.   I suppose that it
> would be best to simply document this.
I don't quite follow this. If a restore using a pg_dump'ed file attempts
to create again an existing language, is this a problem? Notwithstanding
this, why not change the LedgerSMB backup option to simply backup
per-dataset via pg_dump?