Select is a good start, procedures would probably work to some extent, though one can imagine that some of the power is lost if for say I wanted to perform an insert into that pseudo table.

I am syncing 10.4 source tree as I write this email.

Thanks so much for peoples fast, detailed and on the topic responses.


On Thu, Mar 27, 2008 at 9:51 AM, Rick Hillegas <> wrote:
Hi Chris,

I may be misunderstanding your question so please bear with me. The
upcoming 10.4 release of Derby will provide a feature called Table
Functions. This will let you make your external data look like a table
to Derby so that you can issue SELECTs against it. The feature is
described by the functional spec attached to this JIRA: DERBY-716. User
documentation for this feature can be found in the alpha Developer's
Guide in a section titled "Programming Derby-style table functions":

This only covers SELECT functionality, however. This will not handle
INSERT, UPDATE, or DELETE on your external data. I think you are asking
whether Derby provides a plugin facility so that you can use Derby to
perform all of these operations against your external data. If your
INSERT/UPDATE/DELETE needs are simple, then you could write database
procedures to handle these operations against your external data.

Hope this helps,

Chris Collins wrote:
> Sorry if people ask this frequently, didnt find a reference to
> anything like this.
> Within some other database platforms one is capable of adding virtual
> tables that could be backed by ones own non persisted data.  An
> example usage can be reviewed in the following book:
> Here the postgres engine is used as the central place for controlling
> an appliance.  Using this as a communication conduit to other
> appliance services.
> Anyway, is there a way to add ones own table that ultimately provides
> the appropriate callbacks to ones own code?
> This would be similar to the SYS* tables.
> Thanks in advance
> Chris