Re: PostgreSQL Top 10 Wishlist

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Joost Kraaijeveld <J(dot)Kraaijeveld(at)Askesis(dot)nl>
Cc: David Fetter <david(at)fetter(dot)org>, PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: PostgreSQL Top 10 Wishlist
Date: 2006-01-19 00:10:36
Message-ID: 20060119001036.GF17896@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Simon Riggs 2006-01-19 00:15:32 Re: No heap lookups on index
Previous Message Glen Parker 2006-01-18 23:56:43 Re: [HACKERS] No heap lookups on index