Hi Jun,
The interface between the Derby language and storage layers is very big.
I think it would be very tricky to port Derby's SQL interpreter to run
against your own storage engine.
Table Functions have many uses but you may have a hard time fitting them
to your problem. To the optimizer, the output of a Table Function looks
like an unstructured heap--the output has no keys and is assumed to be
unsorted. For this reason, you may lose much of the value provided by
the indexes in your storage engine. In addition, Table Functions are
read-only tuple streams and you cannot use them to insert/update/delete
rows in your store. (You can, however, use database procedures to write
to your external store.)
Your problem is very interesting but is not what the ANSI committee had
in mind when they designed Table Functions. Table Functions may be
useful to you but please be aware of their limitations.
Hope this helps,
-Rick
Jun Yang wrote:
Found likely answers in archive:
http://www.nabble.com/Design-Question-to14136612.html#a14138820
http://www.nabble.com/Table-Function-Question-to14534016.html#a14534016
which points to table functions. Then my question is, can I update
foreign tables too? I need to support both read and write.
Thanks!
Jun
On Sat, Mar 29, 2008 at 4:16 PM, Jun Yang <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi all,
I already have a proprietary database with its own table and index
format. I'd like to use Derby's SQL compilation and execution on
top of my database. Is this possible? I guess if there are
interfaces of table and index etc. I can reimplement them on top
of my own database. Is this feasible at all?
Thanks!
Jun
