Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!pasteur!postgres!jas
From: jas@postgres.uucp (James Shankland)
Newsgroups: comp.databases
Subject: Re: Parsing Query Languages in the Client or Server
Message-ID: <17450@pasteur.Berkeley.EDU>
Date: 21 Sep 89 06:10:00 GMT
References: <6155@sybase.sybase.com>
Sender: news@pasteur.Berkeley.EDU
Reply-To: jas@postgres.berkeley.edu (Jim Shankland)
Organization: Postgres Research Group, UC Berkeley
Lines: 19

In article <6155@sybase.sybase.com> forrest@sybase.com writes:
>I'd like to hear peoples [sic] comments about the strengths and weaknesses
>of [parsing a query in the client & sending a parse tree to the server,
>vs. sending query language to the server & letting the server parse].

Not sure it makes an awful lot of difference -- parsing a query is pretty
cheap, compared to all the other work that has to be done to compile it.
("Parsing" here means just the context-free stuff; the semantic checking
pretty much has to be done in the server, which has the system catalogs.)

As you note, parse trees may be more compact than query language (read
"SQL"); and syntax errors can be caught in the client.  On the other
hand, passing readable stuff back and forth may make for easier
debugging.  Also, given that SQL has become the relational *lingua
franca*, sending SQL to the server may make interoperability easier.
As a matter of commercial practice, I'd say sending SQL to the server
is the way to go.

jas