> First question: should we discuss external functions here as well or
> is this a subject of a separate talk?

Only after you present a description how the stored functions will
work in Firebird.

> I don't like the idea of self-registering modules. They could be
> 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.

That would limit the possibilities that modules can provide. For
example, if somebody wants to create a "full-text search module" that
provides

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 be
> required to be tolerant to being called multiple times.

Why? Usually this requirement comes together with unclear
specification when what to close.

> I'd restate this as: "It is prohibited to access the internal
> database attachment from threads spawned from within the external
> procedures".

Ok.

> And I'd expect the implementation (the engine?) to return an error
> otherwise.

How are you going to detect this?

> I see no problems with spawning multiple threads for the
> computation/communication purposes, neither with accessing
> databases via new explicitly made attachments.

I see already a problem here - you loose control over your child
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 procedure
> called via EXEC PROC returned a result set object or should it
> silently ignore the result set?

Depends on the procedure declaration, I'd say.

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

Roman