| From: | "Phil Currier" <pcurrier(at)gmail(dot)com> |
|---|---|
| To: | "Gregory Stark" <stark(at)enterprisedb(dot)com> |
| Cc: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Column storage positions |
| Date: | 2007-02-21 21:17:19 |
| Message-ID: | c58979e50702211317s3df4ac7ct5cb2af2dbaed1008@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2/21/07, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> 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...
If people are ok with that answer, then I'll gladly stop suggesting
that ALTER TABLE be able to explicitly set storage positions. I was
just trying to avoid forcing a tool like pg_migrator to muck with the
system catalogs.
phil
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2007-02-21 21:32:49 | Re: Column storage positions |
| Previous Message | Gavin Sherry | 2007-02-21 21:07:32 | Re: Status of Hierarchical Queries |