Re: full featured alter table?

From: Shane Dawalt <shane(dot)dawalt(at)wright(dot)edu>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: full featured alter table?
Date: 2003-06-17 14:05:48
Message-ID: 3EEF203C.9060703@wright.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Mattias Kregert wrote:
>>>>>Presentation order should be done at the application level.
>>>>
>>>I agree.
>>>Use a VIEW for the presentation!
>>
>>Sorry, but I don't fully agree with you. If I have to add a new column
>>in a table, this column will appear in the end of the table. What we are
>>talking about (as I understand) is to have the possibility to order the
>>columns table (via ALTER TABLE ...POSITION..). SELECT * FROM <table>
>>would use that order to display the columns.
>
>
> 3. In the case of an quick-and-ugly "just dump out all data" report: Ok, here we have the only situation when a SELECT * could be of any use...!!
>

I have been following this thread with great interesting and
perplexity. I have yet to understand the reasoning behind this proposed
addition. It seems useful only for SELECT * yet most posts say that
"SELECT *" is bad in an app. Others say that if SELECT * is used then
the app has to look for the proper column(s) anyway so ordering is not
important. As stated in the parent post from Mattias Kregert (with whom
I completely agree with), SELECT * is generally always a quick-n-ugly
check of the table. Surely us humans can adapt to the column positions
for checking tables once in a while. And what if an application,
expecting a pre-defined order, receives a column in a position that it
doesn't expect? Wouldn't it still be better to define the column order
in the SELECT statement or just look for the column it wants in the
table information?

Insofaras rearranging the internal table is concerned, I don't
believe the pg people had that intent in mind at all. It may have been
the intent of the original poster, but I think most everyone agrees that
the back-end knows far better than us humans what is more optimal for
table layout.

It just seems that this is extra work for little benefit.
Applications that allow people to move columns for cosmetics should deal
with the storage of that application specific configuration data. If
you use multiple applications that permit customization of column
positions then it falls upon each application to store the configuration
data as it sees fit.

Shane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message sector119 2003-06-17 14:25:23 Re: tsearch - v2 new dict
Previous Message Shridhar Daithankar 2003-06-17 13:49:19 Re: postgreSQL on NAS/SAN?