Andrew, The Tom's message was in Dec/2006. We are in 2010.
Sincerelly, I'm not afraid to seem naive, but I believe that a column that inherits the persistent semantics of attnum solves the 99.9% problem with column reordering of legacy software. The exceptions seems to be: 1) software that address buffers based on attnum. Tipically a core/hacker software. 2) INSERTs without naming the columns. This could be solved when attnum become changeable with a server ou database variable *allow_attnum_changes* with false default value. The problem addressed by Tom about the need of a primary key for attributes is almost the same of the current solutions to reorder the columns: a) recreate the table b) "shift" the columns. Nilson On Tue, Jul 27, 2010 at 6:45 PM, Andrew Dunstan <and...@dunslane.net> wrote: > > > Nilson wrote: > > Quoting "wiki.postgresql.org/wiki/Alter_column_position < >> http://wiki.postgresql.org/wiki/Alter_column_position>" : >> >> "The idea of allowing re-ordering of column position is not one the >> postgresql developers are against, it is more a case where no one has >> stepped forward to do the work." >> >> Well, a hard journey starts with a single step. >> >> Why not, in the next release that requires to run initdb, add a *attraw* >> column (a better name is welcome) in the catalog that stores the physical >> position of column forever, i.e., the same semantics of *attnum*? >> >> Then, in a future release - 9.1 for example - the postgres team can make >> *attnum* changeable using something like ALTER COLUMN POSITION? >> >> Pros: >> >> - Requires only a couple of changes in main postgreSQL code. It seems to >> be very simple. >> >> - Allows a smooth and decentralized rewrite of the whole code that may >> needs the *attraw *attribute - postgreSQL, contribs, pgAdmin, drivers, >> tools etc. This will give time to developers of that code to detect the >> impact of semantics change, make the arrangements necessary and also allow >> the release of production level software using the new feature before >> *attnum *becomes changeable. >> So, when *attnum *becomes read/write, all that software will be ready. >> >> Cons >> >> - More 4 bytes in each row of the catalog. >> >> Nilson >> > > > Please review the previous discussions on this. In particular, see this > proposal from Tom Lane that I believe represents the consensus way we want > to go on this: < > http://archives.postgresql.org/pgsql-hackers/2006-12/msg00983.php> > > cheers > > andrew >
