On Wed, 18 Jan 2006, Jim C. Nasby wrote: > On Wed, Jan 18, 2006 at 08:10:07AM +0100, Joost Kraaijeveld wrote: > > On Tue, 2006-01-17 at 09:52 -0800, David Fetter wrote: > > > On Tue, Jan 17, 2006 at 10:28:03AM -0600, Tony Caduto wrote: > > > > As long as we are talking wish lists... > > > > > > > > What I would like to see is some way to change the ordering of the > > > > fields without having to drop and recreate the table. > > > > > > Why are you asking us to optimize the 'SELECT *' case which almost > > > never belongs in production code in the 1st place? > > Because a lot of tools that I use to manage a database during > > *development* (e.g. PgAdmin) show the columns in an other order than the > > order of attributes in my Java/C++ code. The "logical" order of the > > columns/attributes can change during development. > > Yeah, this isn't about production code, it's about making life easier on > developers. Humans naturally want to group data into natural sets, so > for example all the fields dealing with a person's address would appear > together. But if you ever have to use ALTER TABLE to add a field you're > stuck with that field being at the end of the table. > > Another consideration is that the best order for people isn't the best > order for the database. For example, grouping fields of the same > alignment together will save space (and depending on the table that > savings can really start to add up). > > It would definately be nice if the end-user concept of column order > wasn't tied to the physical order in the database. I agree with that. However, I'm not sure that an ALTER TABLE that reorders a logical column set is necessarily the right way to handle the issue. I think that the same path leads to realizations that a single logical ordering may not be sufficient for development. For example, I could see cases where say person A wants all the address columns together but person B only cares about country and wants the columns he deals with together in some other fashion.
