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.