Aleksey Karyakin wrote:

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

A trigger can be written in existing trigger language to call an
external procedure. There is no reason to extend the trigger mechanism
to support external triggers, per se.

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

Most of these are neither feasible or desirable. Full text indexing,
for example, requires access to database pages, an internal service I
highly doubt we want to export. But even if this were addressed, how
possibly could the code generation/optimization/execution mechanism be
tied in?

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

I agree that commit, prepare, and rollback notification should be made
to external procedure facility. Clearly more design is required.

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

This is a very poor candidate for external procedures.

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

This is outside the scope of the discussion.


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376