Re: full featured alter table?

Поиск
Список
Период
Сортировка
От Shane Dawalt
Тема Re: full featured alter table?
Дата
Msg-id 3EEF203C.9060703@wright.edu
обсуждение исходный текст
Ответ на Re: full featured alter table?  ("Mattias Kregert" <mattias@kregert.se>)
Ответы Re: full featured alter table?  (Sven Köhler <skoehler@upb.de>)
Re: full featured alter table?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: full featured alter table?  (Sven Köhler <skoehler@upb.de>)
Re: full featured alter table?  ("Jim C. Nasby" <jim@nasby.net>)
Список 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


В списке pgsql-general по дате отправления:

Предыдущее
От: "Shridhar Daithankar"
Дата:
Сообщение: Re: postgreSQL on NAS/SAN?
Следующее
От: sector119@mail.ru
Дата:
Сообщение: Re: tsearch - v2 new dict