Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jan 28, 2009 at 10:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Sure, but the other way is just a complete non-starter.
> 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.
Dropped columns are certainly an issue, and TOAST pointers are another,
but they seem to me to be soluble with relatively limited impact
(I don't think pg_dump necessarily needs to be involved; rather I'd
imagine pg_upgrade itself adjusting the new catalog entries after it's
used pg_dump to do most of the work). Trying to do catalog upgrade
in-place is going to be a complete mess. I'd be interested to know,
for example, how you imagine rearranging the contents of pg_class would
work. You don't get to modify pg_class if you can't even find it, which
you can't because you can't read it. And in the time it takes you to
think of an approach for that, I will be able to think of a dozen more
that are all equally nasty. There are probably some thousands of places
in the backend where we expect the system catalogs to have layout
matching what the code expects.
regards, tom lane