Re: POSS. FEATURE REQ: "Dynamic" Views
От | Chris Travers |
---|---|
Тема | Re: POSS. FEATURE REQ: "Dynamic" Views |
Дата | |
Msg-id | 43109DBD.1080705@travelamericas.com обсуждение исходный текст |
Ответ на | Re: POSS. FEATURE REQ: "Dynamic" Views (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
Tom Lane wrote: > > >But why exactly is this a good idea? > Especially since it seems one could write PLPGSQL functions to emulate this if it was so important. The lack of PLPGSQL functions to do this seems to indicate that it is not worth the trouble, >It is oft-repeated advice that you don't use >"SELECT *" ever in production programming, because your applications >will break as soon as any columns are added (or removed, even if they >don't make any use of those columns). > With all due respect, I often use SELECT * in production programming becuase the languages I write in allow me to return the results as a hash table. In this case, things only break if you delete a needed column, and added columns have no real effect unless they are of substantial size (but this is a separate issue). With a good RAD environment (such as Python, Perl, or PHP), I don't think that SELECT * is unduly dangerous. > The proposed dynamic view >facility would move that instability of results right into the views. > > Again, this would not be *that* hard to do with PLPGSQL and a function like redefine_view(name, text) which would store the definitions of the views in a temporary table, and then rebuild dependant views. Again the fact that it is not commonly done indicates simply that there is no need. Best Wishes, Chris Travers Metatron Technology Consulting
В списке pgsql-general по дате отправления: