>> What exactly means "future compatible with C++ client API"?
>>
> Aren't we going to somewhere in the future have a C++, JDBC-like (!=
> identical) API?
>
> Attachment and Transaction will be equivalent to Connection.
> [External]ResultSet of selectable procedure has nothing to do with
> client ResultSet.
>
> Client ResultSet may encapsulate Value and Values or may make they
> accessible.

This was never discussed - that was Jim's idea, but I do not know about
any such decision/discussion in this, devel or admin list... It is also
not in tracker...

>> As to the Value interface - I'm ok with it as long as it supports
>> getters/setters for UTF8 strings.
>>
> There will be three type of encoding transliteration:
> 1) For the plugin metadata handling
> 2) For data exchange (parameters and exceptions) in
> function/procedure/trigger
> 3) To attach to user (self) database - as user connection charset should
> not interfere in ESP, that is another client
>
> This solves all needs.

Fine.

>>
>>> Proposed C++ API offers legacy handles to be used with current official API.
>>>
>> There's one issue with such model - it requires TLS in plugin.
>
> Where you see TLS required? All handles are accessible via structures
> passed by the engine to the plugin.
> Way to obtain connection and transaction handle is encapsulated inside
> ExternalContext.

It is needed when callback is used, at least in JDBC. Note, a way to
obtain a connection in Java ESP according to "de-facto" SQLJ standard is:

public static someJavaProcedure(int param1, String param2) throws
SQLException {
Connection connection =
DriverManager.getConnection("jdbc:connection:default");
....
}

I see no real chance to pass any parameter to a code that obtains a
connection except TLS in plugin...

> AFAIU, this requires TLS.

Yes, but in the engine - not visible to plugin.

> But I have no problem to have this, also it's in my plans to have it.
> It makes connection to database automatically usable in Delphi, for example.

Yes, that was the idea.

> For the transaction obtained via special TPB, what should be the
> behavior of COMMIT and ROLLBACK? Should it act in a savepoint?

Currently we throw an exception in JDBC code, but a savepoint behavior
is also ok.

Roman