Re: pg_upgrade project status

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I really like this idea, assuming I understand it. Basically, I think
> you're proposing that we move the old system catalogs out of the way,
> bootstrap a new catalog, and then using SQL (running inside a
> standalone backend?) to migrate data from the old catalog to the new
> one. That sounds really good to me. Even a relatively complicated
> catalog reorganization should be able to be handled this way without
> too much work or a lot of special-purpose code.

Well, what it really means is that all the special-purpose conversion
code is in SQL instead of C. Which is sort of good as long as whatever
transformation you have in mind can be done easily in SQL. (Good luck
if you need to control the OIDs of the inserted rows, for instance.
And I *really* want to see Zdenek handle conversion of stored-rule query
trees in SQL...) But far more importantly, it doesn't fix the problem
that you have to write conversion code in the first place.

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 ;-). The more
important point is that once we're done with those two issues, we're
done, and will stay done for the foreseeable future (at least with
respect to catalog upgrades).

I am not sure why everyone is so hot to create a conversion path that
guarantees extra maintenance pain for every future catalog
reorganization, when it would be no more complex to create one without
such a burden.

regards, tom lane