| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Phil Currier <pcurrier(at)gmail(dot)com> |
| Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, "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:32:49 |
| Message-ID: | 20070221213249.GE25424@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Phil Currier escribió:
> 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.
I am ... that would be pg_migrator's goal anyway. And it's certainly
going to need knowledge on how to go from one version to the next.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephan Szabo | 2007-02-21 21:51:55 | Re: Column storage positions |
| Previous Message | Phil Currier | 2007-02-21 21:17:19 | Re: Column storage positions |