[
https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12490163
]
Rick Hillegas commented on DERBY-716:
-------------------------------------
Thanks again for the feedback, Dan.
Dan> 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.
Sounds good to me. Maybe something shorter like DERBY_JDBC.
Dan >"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 Dan >Function."
Dan > 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 will clarify this in the next rev of the spec. Here's the point I was trying
to make. Please let me know if this is still confusing: The user will write a
VTI, say myVTI. When the user issues "select * from TABLE( myVTI( ... ) )",
Derby will hand back a ResultSet, say an EmbedResultSet20. The original CREATE
FUNCTION statement determines the shape of the metadata returned by
EmbedResultSet20 regardless of the shape of the metadata returned by
myVTI.getResultSetMetaData().
Dan >I don't see from the functional specification how VTICosting is tied in?
What does the app developer do?
Thanks, I will explain this in the next rev of the spec.
Dan > How about the Pushable interface, that's useful existing functionality as
well?
I don't see any implementations of Pushable in the Derby diagnostic VTIs. Was
this interface ever really used or is it, like VTIEnvironment, part of
someone's future plans?
In any event, I was only spec'ing read-only table functions, that is, ones that
implement ResultSet. From its javadoc, Pushable seems to apply to read-write
VTIs that implement PreparedStatement.
> 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.
