Toward a column reorder solution
in [PgSql]
|
Prev: [HACKERS] Toward a column reorder solution
Next: Review: Re: [PATCH] Re: [HACKERS] Adding xpath_exists function
From: Andrew Dunstan on 27 Jul 2010 17:45 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 27 Jul 2010 17:51 On Tue, Jul 27, 2010 at 5:45 PM, Andrew Dunstan <andrew(a)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> Alvaro is planning to work on this for 9.1, I believe. http://archives.postgresql.org/pgsql-hackers/2010-07/msg00188.php -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 27 Jul 2010 17:56 Robert Haas wrote: >> 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> >> > > Alvaro is planning to work on this for 9.1, I believe. > > http://archives.postgresql.org/pgsql-hackers/2010-07/msg00188.php > > Yay! cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Joshua D. Drake" on 27 Jul 2010 18:01 On Tue, 2010-07-27 at 17:56 -0400, Andrew Dunstan wrote: > > Robert Haas wrote: > >> 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> > >> > > > > Alvaro is planning to work on this for 9.1, I believe. > > > > http://archives.postgresql.org/pgsql-hackers/2010-07/msg00188.php > > > > > > Yay! Correct. We are also hoping to get some sponsorship for it. https://www.fossexperts.com/ Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Nilson Damasceno on 27 Jul 2010 18:03
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(a)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 > |