Re: POSS. FEATURE REQ: "Dynamic" Views

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: POSS. FEATURE REQ: "Dynamic" Views
Дата
Msg-id 1125427715.28179.89.camel@state.g2switchworks.com
обсуждение исходный текст
Ответ на Re: POSS. FEATURE REQ: "Dynamic" Views  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
On Sat, 2005-08-27 at 09:48, Tom Lane wrote:
> "Jim C. Nasby" <jnasby@pervasive.com> writes:
> >> How is this different from materialized views, which is already on the
> >> TODO list?
>
> > The idea behind the DYNAMIC VIEW is that if you made a DDL change in the
> > table it could be reflected in the view. So for example, if you defined
> > a view as SELECT * FROM table; and then added a field to the table that
> > field would also show up in the view.
>
> But why exactly is this a good idea?  It seems like an absolutely
> horrible idea to me.  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).  The proposed dynamic view
> facility would move that instability of results right into the views.
>
> What's more, I cannot see any benefit to be gained over just issuing
> the expanded query directly.  You couldn't layer a normal view over
> a dynamic view (not having any idea what columns it'll return), nor
> even a prepared statement, because those things nail down specific
> result columns too.  So it's just an awkwardly expressed form of
> query macro that can only be used in interactively-issued commands.
>
> I think the burden of proof is on the proponents of this idea to show
> that it's sensible, and it doesn't deserve to be in TODO just because
> one or two people think it'd be nice.

Actually, I've written a few very abstracted database applications that
basically did a select * and then used the libpq stuff to find the
column names and types and such and put the data on the screen in an
edit form.  Such applications know NOTHING about the actual structure of
the table or view they are operating on, and rely on getting said data
from the database.

This makes them very portable.  Need another instance of such an app and
all you need to do is copy in the files and edit one or two config lines
to tell it which table(s) to hit and you're gold.

So, there are certain types of applications where select * is pretty
useful.  I'm not saying I like the idea of dynamic views, but I can see
in a few circumstances where they might be useful.  I can see far more
where they can cause headaches galore.

Just pointing out that some applications naturally lend themselves to
select * is all.

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

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: GROUP BY requirement
Следующее
От: Tony Caduto
Дата:
Сообщение: 8.1 observation