Adriano dos Santos Fernandes wrote:

> Stephen Boyd escreveu:
>
>> I guess that GPRE is my pet peeve, because I use it. Not just for
>> Cobol but for C as well. Am I really that wrong in thinking that GPRE
>> should be consistent with DSQL?
>>
> I'm not against embedded SQL.
>
> As I told, it could be implemented using the DSQL API.
>

Actually, I don't think it could. GPRE was designed as a balance
between ease of use and performance. For ease of use, it handles clean
language extensions that allow arbitrary database field references in
host language statements and host language expressions in DML
statements. This is a level of integration that DSQL can't provide.
For performance, GPRE handles DMLat compile time, generating BLR that is
faster to process than SQL, doesn't require four copy operations per
field (is it only four?), and automatically caches and reuses compiled
requests. A program written with GPRE will be smaller, simpler, easier
to write and maintain, and will blow the doors off the same program
written with DSQL.

The full benefits of GPRE come with GDML, which was designed for
embedding. Borland chose to pretend that GDML didn't exist, so all the
dual language tools -- GPRE and QLI -- suffered serious neglect.

By and large, the world isn't interested in preprocessors. Machines
have gotten bigger and faster, so the performance benefit is less
important than it once was.

That said, I do think it is time to wean the engine build from GPRE in
favor of embedded SQL DDL processed at startup time to define the core
system tables in memory. Getting rid and met.e and his friends would be
a big step forward.

> We need it as it is now because the build uses it.
>
> If we don't need it in the build, I would vote to deprecate/remove the
> *current GPRE* and all (GDEF and maybe QLI in the future) obsolete (or
> better saying, that a very small number of users uses) utilities from
> the codebase.
>
>
>