All,

Currently, external engines routines have only EXTERNAL NAME (and
ENGINE, of course) clauses. The point is, they doesn't have a body like
PSQL procedures and triggers.

More information than the name (which is the "entry point") is in many
cases necessary. Lets say, user created an external trigger capable of
replicate changes to a different database. But the code of this trigger
is generic, and in the database there may be tables replicating changes
to different databases, or a same table replicating changes for more
than one database.

Till now, I had adopted follow approach. The plugin decodes the external
name, and he can do anything with it. One of the things the UDR plugin
does is to separate the name in two pieces, split ed with an exclamation
point. It then interprets the entrypoint using the left side, and the
right side is available for the user routine, as an "information"
string. User can use that info for anything, and the external function
interprets it. In my replication triggers example, that could be a
configuration name, with may be described in details in another table.

This is not sufficient for many cases that I would like the external
engines act. For example, there may be external procedures capable of
doing queries against other databases, or importing XML or any other
files. Here is a possible example of how it could be:

create procedure query returns (
id integer,
name varchar(60)
)
external name 'Query.query(ProcedureContext) returns
ExternalResultSet!some_database'
engine java
as
q'{
select id, name
from person
}';

[ There is where the new quotation syntax works great. ;-) ]

And that is my other wish. Instead of only external name and engine,
external routines could also have a body. It should be optional, and
maybe even the external name could be, but at least one of NAME/body
shall be specified.

That body will be stored on the normal source column present on system
tables, that currently is always NULL for external routines.

This would create a very powerful feature to do important things without
need to code special versions of external routines and adding parameters
to them and create wrappers around.

Also, with abilities for external routines to read "all parameters" [via
ProcedureContext.getInputValues()/.getOutputValues()], that shall be the
way to put Javascript or other Java script languages on the server side.

Comments?


Adriano