On Thu, Jul 26, 2012 at 11:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> On Thu, Jul 26, 2012 at 11:02 AM, Mike Christensen <mike@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