Re: pg_upgrade project status

On Wed, Jan 28, 2009 at 10:52 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
>> Heikki Linnakangas píše v st 28. 01. 2009 v 09:24 +0200:
>>> Right, the dump+initdb+reload approach works quite well in both
>>> pg_upgrade and pg-migrator. I believe the biggest issue with that ATM is
>>> supporting dropped columns, and maybe there's something else, but it's
>>> fairly robust and works across any versions.
>
>> It works but it is not ideal.
>
> Sure, but the other way is just a complete non-starter. It's enormous
> amounts of work even for simple changes, and it's not hard to think of
> potentially-desirable catalog rearrangements for which it would be
> completely unworkable.

Well, the goal of coding is to make such things easier. Already the
solution you're advocating has one huge wart: the need to represent
dropped columns in pg_dump output. It seems optimistic to assume that
there won't be any more, and it seems possible that some change might
happen that requires the wart without the necessary wart actually
getting inserted. We'll end up testing after the fact to see whether
in-place upgrade has gotten broken, and given that no one was under
any pressure to give it some forethought in advance, the answer will
probably be "yes", at least sometimes...

I'm not dead set against doing it this way, I'm just not sold on it.

...Robert