Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!amdahl!rtech!llama!jas
From: jas@llama.rtech.UUCP (Jim Shankland)
Newsgroups: comp.databases
Subject: Re: Call Interfaces to RDBMSs
Message-ID: <1116@rtech.UUCP>
Date: Fri, 7-Aug-87 13:18:53 EDT
Article-I.D.: rtech.1116
Posted: Fri Aug  7 13:18:53 1987
Date-Received: Sun, 9-Aug-87 10:40:09 EDT
References: <168@bernina.UUCP>
Sender: news@rtech.UUCP
Reply-To: jas@llama.UUCP (Jim Shankland)
Organization: Relational Technology, Inc.
Lines: 25

In article <168@bernina.UUCP> marti@ethz.UUCP (Robert Marti) writes:
>The prevalent approach to offer set-oriented access to a relational
>database from an application written in a langauge such as C seems
>to be pre-compilation....
>
>There are two drawbacks to such a solution:  The first and minor one
>is that such constructs look unpleasant in the source.  The second
>and major drawback is that a pre-processor has to written for each
>new host language for which database access has to be supported....
>
I would add to the list of disadvantages:  it makes it hard to use existing
language-sensitive tools such as syntax-directed editors, pretty-printers,
call-graph generators, etc., since ESQL/C (for example) is effectively
a new programming language.

Add 1 major advantage:  all type-checking and conversion is done
automatically.  The scanf-style call interface will happily read
a bit pattern representing a floating point number into an integer
variable; an embedded language preprocessor can do the type conversion.
Finally, polymorphic functions like scanf/printf may be hard or
impossible to write in some languages.
Jim Shankland
 ..!ihnp4!cpsc6a!\
                  rtech!jas
.!ucbvax!mtxinu!/