Re: full featured alter table?
От | Greg Stark |
---|---|
Тема | Re: full featured alter table? |
Дата | |
Msg-id | 87smqagnmd.fsf@stark.dyndns.tv обсуждение исходный текст |
Ответ на | Re: full featured alter table? (Bruno Wolff III <bruno@wolff.to>) |
Список | pgsql-general |
Bruno Wolff III <bruno@wolff.to> writes: > It is already a bad idea to use * in applications in case something does > change the order or number of columns. * is mostly going to be used in adhoc > queries where you care about saving some typing. Since this seems to have gone by without any contention I'll throw in 2c on the other side of this argument. I agree 100% with the logic but reach the opposite conclusion. One of the main goals of program design is to isolate the places that would have to be edited to accomplish any changes. If you explicitly list every or nearly every column in your queries, then whenever a new attribute is added you'll have to go through and add the new attribute to every query that fetched it. Whereas if you use select * and make the presentation code handle any columns that appear in the result then adding a new column can be done purely in the database. The query and the presentation layer can adapt without changes. Of course it's not always possible to achieve this 100%. Often the presentation layer wants to do specific formatting for each attribute and doesn't want to display every single attribute. But using select * means there's one fewer place that needs to be edited to effect the new column. This all depends on having a driver that gives you an API that lets you access columns by name rather than position though. -- greg
В списке pgsql-general по дате отправления: