On Tue, 13 Jul 1999, Jan Wieck wrote:
> > > The way Jan explained it to me, a view *is* a table that happens to
> > > have an "on select do instead" rule attached to it. If the table
> > > has data in it (which it normally wouldn't) you can't see that data
> > > anyway because of the select rule.
> >
> > Does anyone else see a problem with this? This sort of approach almost
> > prevents views with distinct, union, order by, etc. from ever being
> > implemented.
>
> Pardon - YES and NO!
>
> After all I think (even if it was a really great job) that
> Stonebraker was wrong. Views cannot be completely implemented
> by rules. That would make it impossibly complicated for a
> query planner.
That was my point. Sure some of these things above could be done, but it's
a dead end of sorts.
> > I don't know what other people use their views for but I use them to store
> > complicated queries. So, in essence it would suffice to store the text of
> > the query with a view rather than faking tables for it, thus confusing all
> > sorts of utility programs.
> >
> > Then again, I'd be interested to know what to developers' idea of normal
> > usage of a view is.
>
> It doesn't count what 95% of our users use view's for. A view
Um, it should though, shouldn't it?
> Well - let's only store the "QUERY TEXT" of a view:
> Now we execute some simple queries:
> Simple enough? All valid SQL statements! Could you now simply
> explain HOW to build the correct final statements by
> incorporating the stored "QUERY TEXT" into the above
> statements?
Well, this would be trivial if you'd allow subselects in the FROM clause.
But now I am beginning to realize that this is the very reason those
subselects in the from clause aren't possible. Perhaps we ought to think
up some math magic there. But I can't think of anything short of a
temporary table of sorts right now.
Anyway, you guys are doing a great job. If I had some more time I'd dig
myself into this business and help out. Until that day, I'm sure you have
your reasons for things to be the way they are, I'm just trying to point
out ideas for improvements.
--
Peter Eisentraut
PathWay Computing, Inc.
