[ http://issues.apache.org/jira/browse/DERBY-716?page=comments#action_12438229 ] Daniel John Debrunner commented on DERBY-716: ---------------------------------------------
I think the syntax of the RETURNS TABLE clause above is incorrect, I don't believe the column definitions are optional. Implementing a table function in Java using ResultsSet is non-standard, here are some notes on the official standard Java mapping: http://wiki.apache.org/db-derby/JavaTableFunctions I do think the ResultSet/PreparedStatement mechanism is much more elegant and powerful though. I don't believe Derby should provide templates for ResultSet and other JDBC classes for VTIs, it's a pain to support those with multiple JDBC versions, and nowadays IDE's provide easy mechanisms to create all the methods of an interface for a given class. > Re-enable VTIs > -------------- > > Key: DERBY-716 > URL: http://issues.apache.org/jira/browse/DERBY-716 > Project: Derby > Issue Type: New Feature > Components: SQL > Reporter: Rick Hillegas > > Cloudscape used to expose Virtual Table Interfaces, by which any class which > implemented ResultSet could be included in a query's FROM list. Derby still > exposes a number of these VTIs as diagnostic tools. However, Derby now > prevents customers from declaring their own VTIs. The parser raises an error > if a VTI's package isn't one of the Derby diagnostic packages. > This is a very powerful feature which customers can use to solve many > problems. We should discuss the reasons that it was disabled and come up with > a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
