Heikki Linnakangas píše v st 28. 01. 2009 v 09:24 +0200:
> Tom Lane wrote:
> > Robert Haas <robertmhaas@gmail.com> writes:
> >> That implies a fairly robust and configurable system for adding to and
> >> rewriting system catalogs, which today we haven't got.
> >
> > And we won't ever have, because it's unnecessary and would be impossibly
> > complex. We know how to do the catalog update: basically, dump, initdb,
> > reload, then move the data in. There are some corner case issues like
> > how to preserve toast table OIDs, but the idea that we are going to
> > invent a special process for each catalog change is just not reasonable.
>
> 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. Supporting dropped column requires lot of
magic which probably will decrease robustness. When you have a
tablespace then there is another shuffling magic which does not seems
like something robust.
And very important thing is that you need old version of postgreSQL
installed, which is something what packagers does not want. Look on
Oracle how does it.
I have idea how to do it without old PostgreSQL version and with
bootstrap process extension which should not be invasive and easily
maintainable. I will send idea latter ... stay tuned ;-)
Zdenek