| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
| Cc: | "Phil Currier" <pcurrier(at)gmail(dot)com>, "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Column storage positions |
| Date: | 2007-02-21 20:50:32 |
| Message-ID: | 87hctfp753.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Florian G. Pflug" <fgp(at)phlo(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2007-02-21 20:55:31 | Re: Column storage positions |
| Previous Message | Bruce Momjian | 2007-02-21 20:02:19 | Re: [HACKERS] Dead code in _bt_split? |