Dmitry Yemanov wrote:

>We now lack a column precision in XSQLDA. We don't have relation aliases. If
>we're going to extend metadata name length, we're required to change XSQLDA.
>The same goes for introducing namespaces/schemas. I see a few possible ways
>to deal with these issues:
>
>1) Extend both isc_dsql_sql_info() and XSQLDA (introducing a new version)
>every time. This is what Borland does now.
>2) Freeze XSQLDA structure (for compatibility reasons) and extend only
>isc_dsql_sql_info(). It doesn't allow us to use longer metadata names or
>namespaces, but may satisfy the current needs.
>3) Introduce new API which uses a new structure (or just simplified XSQLDA)
>for input/output data only and returns all relevant describe information via
>isc_dsql_sql_info().
>
>
>

Fundamentally, we need a better SQL API. The current one is ugly, hard
to use, non-extensible, and requires copying the data over and over and
over as it traverses the various layers and plumbing. The model I have
is mind is a lower level API that is:

1. Message oriented. All data is transmitted as a self described
byte stream.
2. Functional: Each entrypoint returns a single value/object.
3. Exception based: Exceptions are thrown, not returned as vectors or
status codes.
4. Object oriented: interface objects (SQL strings, data messasges)
are passed as objects

I see at least two clients for the new API: The existing DB2-extended
API and the C++ binding of the JDBC interface used in IscDbc and the
internal SQL implementation. If you wish, you could add a
DB2-extended-twice API as a third. In all likelihood, somebody with
make (or adapt) a nice set of Delphi classes as well.

If we define the objects well, smart tools will want to use the new API
directly. Legacy programs will continue to use what they currently know
and hate. New programs will probably opt to use the JDBC binding.
[Open question: should be API defined defined to allow emulation against
the old API?].





--

Jim Starkey
Netfrastructure, Inc.
978 526-1376