> And I explained that the API was defined to follow JDBC 1.2 as
> closely as possible. The DatabaseMetaData calls are intended to let
> a client know how about how the underlaying system handles things,
> just as in Java. They are potentially useful to both Java code and
> non-Java language processors.
>
> The design is intended to support the thinest possible layer between
> a Java JDBC based procedure and the database engine. You prefer a
> fat layer, but someone else may decide that a thinner layer is
> faster and less of a maintenance burden.

Maybe... but only if that someone would like to stay with JDBC 1.2,
but considering JDBC 4.0 to be released next year... I know how much
code in JayBird is responsible for JDBC compatibility, and what does
it mean to be JDBC-compatible.

And you did not answer how tiny that layer would be for other
components, like IBX/FIB/IBO for those willing to code in Delphi, or
.Net with their ADO component model.

> I don't think you should object to functionality that is useful to
> other people just because you don't plan to use it. Besides, as
> internal SQL changes, you might decide that these calls are actually
> more informational than building in knowledge of all possible
> Firebird version strings.

Sure. I definitely not object to the solution that satisfies others.

And regarding to the calls, it is definitely more informational than
version strings. Unfortunately you cannot rewind the history and add
them to Firebird 1.0 and 1.5, so version string have to be supported.

> >Yes, and I agree. The question is not what internal functions will
> >be called, but what API is presented to the client.
> >
> Also how they are to be called and how transaction context is passed
> to the language processor.

As you suggested, the "API" object will be passed into the call. In
your case its InternalConnection, in case of ISC API some db handle
and tr handle would be enough.

> The problem is that the current ISC API is soon to be relegated to a
> client side layer on top of a more efficient API. Much of what you
> consider the current API disappears inside of the client side
> Y-valve and isn't supported in the engine at all. Building in the
> old SQLDA-based interface makes no sense at all.

Well. When it disappers, I will adopt a new API, but so far I do not
feel to be an early adopter for something that would need complete
rewrite of JayBird.

> If you have some ideas, float them now. If you think a database API
> can be designed in a few hours over a few beers, I'm afraid you're
> in for a disappointment. And given the reputation of the local
> brews...

I have started that by checking the existing components (.Net, PHP,
Delphi), what they need from the API, but nothing finished yet.

Roman