Re: pg_upgrade project status - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: pg_upgrade project status
Date
Msg-id 200901291133.52079.peter_e@gmx.net
Whole thread Raw
In response to Re: pg_upgrade project status  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_upgrade project status  (Greg Stark <greg.stark@enterprisedb.com>)
List pgsql-hackers
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.


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Hot standby, recovery infra
Next
From: Stefan Kaltenbrunner
Date:
Subject: Re: Commitfest infrastructure (was Re: 8.4 release planning)