|Subject||Re: External procedures: implementation proposal.|
> First question: should we discuss external functions here as well orOnly after you present a description how the stored functions will
> is this a subject of a separate talk?
work in Firebird.
> I don't like the idea of self-registering modules. They could beThat would limit the possibilities that modules can provide. For
> described via the manifest files or they could contain a pre-defined
> describe() call, but this is the engine that decides to write
> something into the system tables.
example, if somebody wants to create a "full-text search module" that
a) tables for internal index data structures
b) procedures/functions that allow to index and search the repository
he must then provide an SQL script that has to be executed to register
stuff in the database. But if the module is allowed to perform some
database tasks automatically during initialization and/or opening the
database, it can do significantly more.
> How is the module name encoded in RDB$EXTERNAL_NAME?It's not. Language is specified. Database engine reads the
RDB$LANGUAGE from the RDB$EXTERNAL_PROCEDURES, then reads the
corresponding module from RDB$EXTERNAL_ENGINE:
SELECT RDB$MODULE_NAME FROM RDB$EXTERNAL_ENGINE ee INNER JOIN
RDB$EXTERNAL_PROCEDURES ep ON ee.RDB$LANGUAGE = ep.RDB$LANGUAGE WHERE
RDB$EXTERNAL_NAME = ?
> Shouldn't the external module be loaded on demand?I would load on server start to avoid any delays on first access and
to see the configuration error right on the start, but I do not have
any strong preference here.
> const char* externalName, please ;-)Ok.
> I think that the ExternalResource::close() implementation must beWhy? Usually this requirement comes together with unclear
> required to be tolerant to being called multiple times.
specification when what to close.
> I'd restate this as: "It is prohibited to access the internalOk.
> database attachment from threads spawned from within the external
> And I'd expect the implementation (the engine?) to return an errorHow are you going to detect this?
> I see no problems with spawning multiple threads for theI see already a problem here - you loose control over your child
> computation/communication purposes, neither with accessing
> databases via new explicitly made attachments.
thread. Then you The computation model should be very similar to the
one in EJB - no threads, no static variables, etc. The execution model
has always explicit start and explicit end. When execution has ended,
no part of the code that was executed is alive.
> Is the engine expected to return an error if the external procedureDepends on the procedure declaration, I'd say.
> called via EXEC PROC returned a result set object or should it
> silently ignore the result set?
- If no OUT parameters are defined and result set is returned - an error.
- If OUT parameters are defined and no result set is present - error.
- If OUT parameters are defined and RS does not contain rows - all
NULLs are returned.
- If OUT parameters are defined and RS contains more than one row - error.
I would throw an error each time something stinky is detected.