Re: Toward a column reorder solution

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 <andrew(at)dunslane(dot)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
>