On Thu, Jul 26, 2012 at 11:19 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Merlin Moncure <mmonc...@gmail.com> writes: >> On Thu, Jul 26, 2012 at 11:02 AM, Mike Christensen <m...@kitchenpc.com> >> wrote: >>> I don't really think you'd need to decouple the internal column order >>> from what the user sees. A REORDER COLUMNS command should re-build >>> the table with the columns in the specified order. > >> That's a controversial point: doing it that way makes reordering of >> large tables highly impractical. > > In particular, if the implementation works like that, you hardly need > any system support at all. You can do the equivalent today with a few > SQL commands: create a new table by selecting columns from the old, > drop old table, rename new into place.
Er, well, if you did that you'd also have to: 1) drop and recreate and foreign keys referring to your table, rebuild triggers, etc 2) drop and recreate and views and functions with a dependency on the table type 3) if you happened to have inlined the table type directly into another table for purposes of storage, punt. (table based composites have seem to suggest only logical reordering is possible anyways unless you want to cascade the physical reorder). Definitely non-trivial. CLUSTER requires a lock, but doesn't require messing around with the RI and other dependencies. You'd still have to work out #3 though. merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
