Roman Rokytskyy escreveu:

>> So I'm proposing a C++ friendly interface, accessible by C and others
>> languages and future compatible with a C++ client API.
>>
>
> 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.

> 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.

>
>> 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.

> I like Vlad's idea of having special DPB/TPB parameters for a current
> attachment/transaction more attractive. Do you have any objections to it?

AFAIU, this requires TLS.

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.

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


Adriano