Re: Column storage positions - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Column storage positions
Date
Msg-id 87hctfp753.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Column storage positions  ("Florian G. Pflug" <fgp@phlo.org>)
Responses Re: Column storage positions  ("Phil Currier" <pcurrier@gmail.com>)
List pgsql-hackers
"Florian G. Pflug" <fgp@phlo.org> writes:

> 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.

The way pg_migrator works is does a pg_dump to move the schema to the new
postgres. Then it transfers the files and drops them into place where the new
schema expects to find them.

So yes, there would be a use case for specifying the physical column layout
when pg_migrator is doing the pg_dump/restore. But pg_migrator could probably
just update the physical column numbers itself. It's not like updating system
catalog tables directly is any more of an abstraction violation than swapping
files out from under the database...

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Column storage positions
Next
From: Andrew Dunstan
Date:
Subject: Re: Column storage positions