"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.
regards, tom lane