Re: PostgreSQL Top 10 Wishlist

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: PostgreSQL Top 10 Wishlist
Дата
Msg-id 20060119001036.GF17896@pervasive.com
обсуждение исходный текст
Ответ на Re: PostgreSQL Top 10 Wishlist  (Joost Kraaijeveld <J.Kraaijeveld@Askesis.nl>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Glen Parker
Дата:
Сообщение: Re: [HACKERS] No heap lookups on index
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: SELECT Rules or stored procedure