Re: [HACKERS] create rule changes table to view ? - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] create rule changes table to view ?
Date
Msg-id Pine.LNX.4.10.9907131401050.5581-100000@saxony.pathwaynet.com
Whole thread Raw
In response to Re: [HACKERS] create rule changes table to view ?  (wieck@debis.com (Jan Wieck))
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] PostgreSQL v6.5 - Tagged
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] Updated TODO list