From: | Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Joost Kraaijeveld <J(dot)Kraaijeveld(at)Askesis(dot)nl>, PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL Top 10 Wishlist |
Date: | 2006-01-19 14:52:47 |
Message-ID: | 20060119064429.N84426@megazone.bigpanda.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, 18 Jan 2006, David Fetter wrote:
> On Wed, Jan 18, 2006 at 04:33:23PM -0800, Stephan Szabo wrote:
> > On Wed, 18 Jan 2006, Jim C. Nasby wrote:
> >
> > > 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.
>
> Although it might be nice to have different column orderings, say
> per-role, the SQL:2003 standard requires a single canonical ordering
> in the information schema. How would we handle both?
That's part of the problem.
I'm not 100% sure where the people who want this are going with the
feature. I've heard a lot of talk about tools, but that's potentially
solvable without changing the canonical ordering as long as the tools obey
not directly using select * internally (if the user asks for it as an sql
statement obviously that's what should get done); and it was done in a
postgresql specific, but documented way, to allow different tools to use
it. If the issue then is that select * doesn't come back in that order,
then we get back into the question of does a single ordering make sense?
If not, and we allow select * to change, then applications and queries
will fail (imagine select * from a union select * from b where different
users are reordering a and b separately).
From | Date | Subject | |
---|---|---|---|
Next Message | Nik | 2006-01-19 15:01:47 | Re: Connections not closing |
Previous Message | Doug McNaught | 2006-01-19 14:34:00 | Re: mount -o async - is it safe? |