Re: Column storage positions

Phil Currier wrote:
> On 2/21/07, Martijn van Oosterhout <kleptog(at)svana(dot)org> wrote:
>> > don't see any good way to perform an upgrade between PG versions
>> > without rewriting each table's data. Maybe most people aren't doing
>> > upgrades like this right now, but it seems like it will only become
>> > more common in the future. In my opinion, this is more important than
>> > #1.
>>
>> I don't see this either. For all current tables, the storage position
>> is the attribute number, no exception. You say:
>>
>> > because the version X table could
>> > have dropped columns that might or might not be present in any given
>> > tuple on disk.
>>
>> Whether they're there or not is irrelevent. Drop columns are not
>> necesarily empty, but in any case they occupy a storage position until
>> the table is rewritten. A dump/restore doesn't need to preserve this,
>> but pg_migrator will need some smarts to handle it. The system will
>> need to create a column of the appropriate type and drop it to get to
>> the right state.
>
> I agree, a dump/restore that rewrites all the table datafiles doesn't
> need to handle this. And I agree that the system will need to create
> dropped columns and then drop them again, that's exactly what I
> suggested in fact. We're talking about pg_migrator-style upgrades
> only here.

Why would a pg_migrator style upgrade use pg_dump at all? I assumed it
would rather copy the verbatim data from the old to the new catalog,
only changing it if the layout of the tables in pg_catalog actually
changed.

greetings, Florian Pflug