Hi!

As you see in my external engine API proposal, it creates something we
current don't have internally. One attachment can have different
properties depending on the context.

For example, it can use one charset to the client and another to the
external engine. It also can have user or sysdba rights.

Different charsets are also needed for future implementation of internal
SQL, as engine SQL is expected to work with metadata (UTF-8) charset
independently of user charset. The same for user / sysdba rights.

To make it work, I need to:
- create a REATTACH y-valve internal function
- create the concept of "pseudo attachments"

A "pseudo attachment" is resolved in DSQL and engine entry points and
changes the real attachment properties and continues with it.* This
seems to not be a problem for multi-thread, as multiple threads can't
use the same attachment simultaneously. (is this simple correct?)

* Dynamic properties can also live in the thread data, but this is
enough for current implementation IMO.

I also need to communicate y-valve handles to engine, as Vlad does in
exec. stmt branch. But the solution Vlad is using doesn't work with
CONNECT and TRANSACTION START triggers, as he said.

I think these handles could be communicated to the engine via internals
DPB/TPB. BTW, isn't the isc_dpb_trusted_role an internal DPB? Should not
we create a generic mechanism for internal DPB/TPB?

And yes Virginia :-), this is one more thing that violates y-valve
layering, but it's how Firebird current works.

And based on my generic API proposal, I shall be in the future proposing
something much better than current Vulcan provider architecture, that
also solve Vulcan problems of:
- need more than one DLL when using embedded
- ugly API, where engine doesn't understand client (DSQL) structures
- necessity of external providers understand BLR

Comments, critics, suggestions?


Adriano