[
https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490115
]
Daniel John Debrunner commented on DERBY-716:
---------------------------------------------
Some comments on the spec:
I think the parameter style should be more specific than "DERBY", say
"DERBY_JDBC_RESULT_SET", there may be other Derby specific types that could be
added here, e.g. RSS.
"When you issue a query against a Table Function, Derby constructs a
ResultSetMetaData for the result, based on the column names and datatypes you
declared when you initially created the Table Function."
Not sure what this is really trying to say. Why would Derby create a
ResultSetMetaData based upon the functions shape, what is this used for?
I don't see from the functional specification how VTICosting is tied in? What
does the app developer do?
How about the Pushable interface, that's useful existing functionality as well?
> Re-enable VTIs
> --------------
>
> Key: DERBY-716
> URL: https://issues.apache.org/jira/browse/DERBY-716
> Project: Derby
> Issue Type: New Feature
> Components: SQL
> Reporter: Rick Hillegas
> Attachments: functionTables.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
