"Jim Starkey" <jas@...> wrote in message
news:42E50A04.90208@......

> I'm sorry, but this doesn't make any sense to me. I have no idea

of

> what triggers have to do with this.

I may be wrong with the topic but as far as I understand the
possibility to extend the server functionality with user-defined or
third-party modules is discussed. Now, the only feasible way a user
can extend server processing is to define stored procedures and
triggers. In fact, trigger is a stored procedure with a special
input/output that is called at some moment. The second alternative -
UDF is very limited in functionality and has no database interface.

If Firebird establish a clear and easy to use extensibility
mechanisms it would be of a benefit to those who develops custom
applications based on Firebird. You could write or connect existing
third-party modules such as full-text indexing, for example. It looks
like any database engine like Oracle, MSSQL or even PG and MySQL ahve
such mechinisms of some sort. Some of them have much more -
extensible optimizers, index types and access methods.

Maybe, the problem of the current discussion is that nobody outlined
the particular goals for the proposed extension mechanisms.

Some examples.

1. A stored procedure that connects to another server and performs
queries against it. Of course, if the original transaction is
aborted, the changes made to the other databases must be rolled back
as well. 2PC is a must there.

Variations: external logging, auditing, replication. There also has
been some buzz about "triggers on commit".

2. A large dataset is distributed across several servers. A central
server contains metadata and logic to split single query accesing all
the data to separate queries sent to other servers. These queries are
performed in parallel on different servers and the results are
consolidated on the original server. A sort of poor man's Distributed
Query Option or Partitioned Views. Yes, a lot af manual work.

3. Custom module with aggregate functions. Nobody has ever wanted
STDDEV or comma-separated list of values ?

4. External interface to ODBC/JDBC/OLE DB data sources to complement
existing dumb external tables.

n. I'm sure there are others.

> The intended purpose of the internal SQL interface

(InternalConnection,

> et al) is to provide a mechanism to export database access and

context

> to loadable modules within the engine. The SecurityDb instances of
> SecurityPlugin, for example, uses the mechanism to do database

lookups:

>
> // We've got some work to do.

If your goal is soley to solve the problem of authentication, it's
not worth generalizing.

Please tell your goals ?

Regards,
Aleksey Karyakin