On Thursday 29 January 2009 01:05:07 Tom Lane wrote:
> The appeal of the pg_dump approach is that it will automatically handle
> everything that there exists a plain-SQL representation for, which is to
> say darn near everything. We will need special purpose code to deal
> with the dropped-column and TOAST-oid issues, but that can probably be
> written in SQL if it makes anyone feel better to do so ;-).
Dropped columns are certainly solvable. You just include the dropped column
in the dumped CREATE TABLE statement and then issue a DROP COLUMN statement
afterwards. You might have to do some extra work if there is a name conflict
between a dropped and a later-added column, but that shouldn't be so hard.
All you need is the space, not the column names, after all.
In response to
pgsql-hackers by date
|Next:||From: Stefan Kaltenbrunner||Date: 2009-01-29 09:37:04|
|Subject: Re: Commitfest infrastructure (was Re: 8.4 release planning)|
|Previous:||From: Heikki Linnakangas||Date: 2009-01-29 09:20:06|
|Subject: Re: Hot standby, recovery infra|