Tom Lane wrote:
Robert Haas <robertmh...@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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
