On Thu, Jul 26, 2012 at 9:12 AM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote: > On Thu, Jul 26, 2012 at 11:02 AM, Mike Christensen <mike@xxxxxxxxxxxxx> 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. Internally, it >> should be no different from making a new table, copying all the data >> over, then deleting the old table. If there's any optimizations that >> can be done (such as making this faster on large tables), those could >> be done in future versions. I'd just like to changing column order >> easier without remaking the table or renaming columns and changing >> their data types (as suggested by Marc) > > That's a controversial point: doing it that way makes reordering of > large tables highly impractical. A column map turns that into a > catalog update which can be done at any time. I would argue that you > can have it both ways: implement the map and have table rebuilding > operations (like TRUNCATE and CLUSTER) opportunistically do the > physical swap. Yea, it all comes down to level of effort. It sounds like adding the ability to store columns in a different order than they're displayed would have a huge development cost associated with it, however it would have some other advantages. For example, perhaps Postgres could always optimize the column order on disk automatically (similar to how a compiler does).. However, once the syntax is defined for how you re-order a column, the underlying implementation could be changed and improved in future versions without breaking changes. Mike -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
