Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!ames!pasteur!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!portal!cup.portal.com!DMasterson
From: DMasterson@cup.portal.com
Newsgroups: comp.databases
Subject: Re: INGRES/EQC and SQL/C ...and general notes...
Message-ID: <8631@cup.portal.com>
Date: 1 Sep 88 03:39:21 GMT
References: <24546@bu-cs.BU.EDU> <2401@rtech.rtech.com> <24585@bu-cs.BU.EDU
Organization: The Portal System (TM)
Lines: 45
XPortal-User-Id: 1.1001.2888

In message <2407@rtech.rtech.com>, davek@rtech.rtech.com writes:
>In article [...] berlin@buita.bu.edu (David Fickes Einstein Project) writes:
>[quoting himself from an earlier posting]
>>> 
>>> One other question. What's so hard about supporting NESTED EQUEL
>>> statements in the EQUEL/C processor???  
>
>This really isn't the pre-processor's choice.  It's giving you a warning 
>when you nest a statement within a retrieve loop only because it was told
>to.  And it was told to simply because retrieve loops weren't designed
>to support that construct.
>
Baloney!  Perhaps Ingres's retrieve loops were designed that way, but that
need not be a restriction.  Britton-Lee had nested retrieve loops in their IDL
preprocessor for the IDM 4 years ago.  This language looks very much like Quel
for Ingres (it was designed by Dr. Epstein who did much of the work on UCB's
Ingres).

>What, then, are they designed to do?  The answer is that the EQUEL retrieve
>loop was designed (and this is more of a DBMS issue than an pre-processor
>issue) as a high-speed "portal" through which you can extract multiple
>rows from the database.  The "high-speed" part is true because retrieve 
>loops are implemented to return lots of rows in user-tuneable "pipeblocks"
>from the back-end to the front-end.  In most cases, even if your front-end
>code isn't ready to accept another row, the back-end (or DBMS) will be 
>finding rows, and filling up pipeblocks full of data to send to the front-end.
>
In a proper configuration, there is nothing to say that nested retrieve loops
couldn't use multiple "pipeblocks".  Only allowing one retrieve loop to be
active prevents users of applications from requesting more info about
something (retrieve details where detail.key = user input) on the fly.  This
causes the application programmer to do ineffecient things to allow this to
happen (join and retrieve ahead of time).

>[lines with bad premise deleted]

You said some pretty flame worthy things there and admitted it yourself.  It
sounded very bias and not a very good answer to the question.

>David Kellogg
>Relational Technology (INGRES) New York City
>davek@rtech.rtech.com

David Masterson
DMasterson@cup.portal.com