| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Zdenek Kotala <Zdenek(dot)Kotala(at)sun(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Subject: | Re: pg_upgrade project status |
| Date: | 2009-01-29 09:33:50 |
| Message-ID: | 200901291133.52079.peter_e@gmx.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stefan Kaltenbrunner | 2009-01-29 09:37:04 | Re: Commitfest infrastructure (was Re: 8.4 release planning) |
| Previous Message | Heikki Linnakangas | 2009-01-29 09:20:06 | Re: Hot standby, recovery infra |