Tom Lane wrote: > > 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. The universal assumption has > been that REORDER COLUMNS needs to work by just adjusting a few catalog > entries, or it's not worth bothering with. But if the table has indexes, triggers, integrity constraints, check constraints, or default values for columns, moving these after a CREATE TABLE AS select ... is not easy. Personally, every time I had the need to reorder columns, having it as a fast operation was irrelevant to me, whereas figuring out how to deal with the above was the time-consuming part. If we had the feature but it was as slow as say, CLUSTER, that would already be quite nice. Best regards, -- Daniel PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
