Adriano, let me answer 2 letters at once - to avoid thread splitting. They are
much related.

On Sunday 30 December 2007 18:57, Adriano dos Santos Fernandes wrote:
> Vlad Khorsun wrote:
> >>>> I think these handles could be communicated to the engine via
> >>>> internals DPB/TPB.
> >>>
> >>> Are you going to pass y-valve handle (or its address) via DPB/TPB ?
> >>
> >> This solve the problem with database triggers.
> >>
> >>> Or i, very probably, not understand something ?
> >>
> >> Since it's from y-valve to internal engine, I see no problem except
> >> establish a generic DPB/TPB mechanism for this.
> >
> > I don't like this hack. I prefer to introduce private
> > jrd8_attach_database2 call with additional argument to do it. I prefer
> > much more to leave it as is until integration of DSQL into engine.
>
> I see that current solution used in exec_stmt2 branch is not needed.
> Better to use EXECUTE STATEMENT solution than introduce more hacks
> (get/set engine handles functions). I.e., better have one, already
> existing hack, than have two.
>
> With small changes in the y-valve, it allows us to use exec_stmt2 and
> external functions even in TRANSACTION START triggers.
>
> It will not be possible to use it in database CONNECT/DISCONNECT
> triggers anyway, because the transaction created is not visible in the
> y-valve.
>
letter 2
> Didn't you agreed that using internal engine handles will be possible
> after DSQL/JRD/Y-Valve re-architecture?
>
> External engines is a client and should be able to use the client API,
> and (unfortunately) it is currently the ISC API.

I think that main difference between old hack in EXECUTE STATEMENT and what is
suggested now for External engines (no matter, what do we use - get/set
engine handles functions, DPB/TPB mechanism, old EXECUTE STATEMENT hack) is
that with introducing external engines, using ISC API with it's handles, we
make that hack public. After DSQL + JRD merge we can easily avoid hacks in
EXECUTE STATEMENT, but please tell - what to do with users applications,
written in assumption that handles in external engine are ISC API handles? We
will have to find ways to make yValve handles known in engine forever. This
is what primarily not good for me.

Wny not introduce poor virtual class based API for external engine? Let it be
simple dup of existing ISC API, let us for a while pass yValve handles and
ISC API functions calls into it. Creating it is not big deal if we do not
want to redesign API seriously. But supporting it later will be much simpler
since we will be at any moment able to replace yValve handles with engine
(provider) handles, ISC API calls with direct engine calls, and all hacks
will be easily gone.