Toward a column reorder solution

From: Nilson <nilson(dot)brazil(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Toward a column reorder solution
Date: 2010-07-27 21:31:48
Message-ID: AANLkTi=pBG9RO=Tf8TP280Tdj_zV5eWQJXsGnB6=Etk5@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2010-07-27 21:45:29 Re: Toward a column reorder solution
Previous Message Robert Haas 2010-07-27 21:18:18 Re: page corruption on 8.3+ that makes it to standby