Manfred Koizar <mkoi-pg@aon.at> writes:
> I tend to believe that every code change or new feature that gets
> implemented is unique by its nature, and if it involves catalog
> changes it requires a unique upgrade script/tool. How should a
> generic tool guess the contents of a new catalog relation?
*It does not have to*. Perhaps you should go back and study what
pg_upgrade actually did. It needed only minimal assumptions about the
format of either old or new catalogs. The reason is that it mostly
relied on portability work done elsewhere (in pg_dump, for example).
> Rod's adddepend is a good example.
adddepend was needed because it was inserting knowledge not formerly
present. I don't think it's representative. Things we do more commonly
involve refactoring information --- for example, changing the division
of labor between pg_aggregate and pg_proc, or adding pg_cast to replace
what had been some hard-wired parser behavior.
> ... I wouldn't call it perfect (for example, I still don't know how
> to insert the new table into template0),
... in other words, it doesn't work and can't be made to work.
pg_upgrade would be a one-time solution for a fairly wide range of
upgrade problems. I don't want to get into developing custom solutions
for each kind of catalog change we might want to make. That's not a
productive use of time.
regards, tom lane
