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