Kaare Rasmussen <kar@kakidata.dk> writes:
> Not sure about your position here. You claimed that it would be a good idea to
> freeze the on disk format for at least a couple of versions.
I said it would be a good idea to freeze the format of user tables (and
indexes) across multiple releases. That's distinct from the layout and
contents of system catalogs, which are things that we revise constantly.
We could not freeze the system catalogs without blocking development
work, and we should not make every individual catalog change responsible
for devising its own in-place-upgrade scheme either. We need some
comprehensive tool for handling catalog upgrades automatically. I think
pg_upgrade points the way to one fairly good solution, though I'd not
rule out other approaches if someone has a bright idea.
Clear now?
> Do you argue here that this cycle shouldn't start with the next
> version,
I have not said anything about that in this thread. Now that you
mention it, I do think it'd be easier to start with the freeze cycle
after tablespaces are in place. On the other hand, tablespaces might
not appear in 7.5 (they already missed the boat for 7.4). And
tablespaces are something that we could expect pg_upgrade to handle
without a huge amount more work. pg_upgrade would already need to
contain logic to determine the mapping from old-installation user table
file names to new-installation ones, because the table OIDs would
normally be different. Migrating to tablespaces simply complicates that
mapping somewhat. (I am assuming that tablespaces won't affect the
contents of user table files, only their placement in the Unix directory
tree.)
I think a reasonable development plan is to work on pg_upgrade assuming
the current physical database layout (no tablespaces), and concurrently
work on tablespaces. The eventual merge would require teaching
pg_upgrade about mapping old to new filenames in a tablespace world.
It should only be a small additional amount of work to teach it how to
map no-tablespaces to tablespaces.
In short, if people actually are ready to work on pg_upgrade now,
I don't see any big reason not to let them ...
regards, tom lane