Re: PostgreSQL Top 10 Wishlist - Mailing list pgsql-general

From Jim C. Nasby
Subject Re: PostgreSQL Top 10 Wishlist
Date
Msg-id 20060119001036.GF17896@pervasive.com
Whole thread Raw
In response to Re: PostgreSQL Top 10 Wishlist  (Joost Kraaijeveld <J.Kraaijeveld@Askesis.nl>)
Responses Re: PostgreSQL Top 10 Wishlist  (Stephan Szabo <sszabo@megazone.bigpanda.com>)
Re: PostgreSQL Top 10 Wishlist  (Michael Glaesemann <grzm@myrealbox.com>)
Re: PostgreSQL Top 10 Wishlist  (Tony Caduto <tony.caduto@amsoftwaredesign.com>)
List pgsql-general
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.
--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

pgsql-general by date:

Previous
From: Glen Parker
Date:
Subject: Re: [HACKERS] No heap lookups on index
Next
From: "Jim C. Nasby"
Date:
Subject: Re: SELECT Rules or stored procedure