Re: pg_upgrade project status

Hm the previous proposal was to add syntax to create table to create
placeholder columns of specified width.

On the one hand the special syntax is less kludgy but on the other
hand keeping all the compatibility code in pg_dump is attractive. Net
I think prefer your solution.

I don't think name conflicts are a problem either since the original
name is long gone anyways. All you need to do is find a type with a
matching width and make a an arbitrary dummy name.

--
Greg

On 29 Jan 2009, at 09:33, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:

> 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.
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers