|Subject||Re: External "procedural engine" modules|
> First of all, I'd follow the Roman's advice and start the discussionI did some quick code checks for the problem (b) (to provide bigger
> in fb-architect. Two questions to be started there: (a) calling
> external code from the looper to process non-native byte code (our
> suggestion - use extra BLR verb for this purpose) and (b) callbacks
> from the external libraries (JVM, UDFs, your BTC plugin, etc) to the
> engine. After the initial discussion we may continue in fb-devel.
part of GDS API to the UDF). It seems that technically it is possible.
Currently we have already some blob manipulation functions exported
for blob UDF through some structure. I think we can define another
structure and fill it with the entry points to most of the DSQL
functions. Also we will have to provide at least transaction handle,
probably also a db handle.
Currently I see only possible problem that DSQL method calls are not
re-entrant, e.g. you should not call isc_dsql_exec2 when you're inside
isc_dsql_exec2 already (for example a select that triggers UDF that in
turn makes call to the engine itself).
What do others think about such approach?