Phil Currier wrote:
On 2/21/07, Martijn van Oosterhout <> 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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to