On 02/27/2015 12:25 PM, Tomas Vondra wrote: > On 27.2.2015 21:09, Josh Berkus wrote: >> Tomas, >> >> So for an API, 100% of the use cases I have for this feature would be >> satisfied by: >> >> ALTER TABLE ______ ALTER COLUMN _____ SET ORDER # >> >> and: >> >> ALTER TABLE _____ ADD COLUMN colname coltype ORDER # > > Yes, I imagined an interface like that. Just to be clear, you're talking > about logical order (and not a physical one), right?
Correct. The only reason to rearrange the physical columns is in order to optimize, which presumably would be carried out by a utility command, e.g. VACUUM FULL OPTIMIZE. > If we ignore the system columns, the current implementation assumes that > the values in each of the three columns (attnum, attlognum and > attphysnum) are distinct and within 1..natts. So there are no gaps and > you'll always set the value to an existing one (so yes, shuffling is > necessary). > > And yes, that certainly requires an exclusive lock on the pg_attribute > (I don't think we need a lock on the table itself). If MVCC on pg_attribute is good enough to not lock against concurrent "SELECT *", then that would be lovely. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
