Phil Currier wrote:
On 2/21/07, Martijn van Oosterhout <kleptog@svana.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
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
