Rick Hillegas (JIRA) wrote:
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.
Well, VTI's can also be written using PreparedStatement's, so that's why
I added the RESULT_SET portion.
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().
The point is valid but not in terms of mentioning JDBC ResultSet or
ResultSetMetaData. This is SQL, a table function defines a table
expression and its column types will be those defined by the function.
The types for JDBC are defined by the select list, not the function
definition directly, i.e. table functions can be used in more than a
SELECT *.
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?
Yes, it was used and worked, it's a useful addition, especially if the
ResultSet is coming from a back-end SQL database.
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.
OK, also the api I think you are proposing would preclude Pushable,
though maybe it can use the same mechanism as the costing api.
Note though that I wouldn't think of the VTIs as ResultSet=Readonly and
PreparedStatement=Read-write. The use of PreparedStatement gives one a
much cleaner separation between compile time and execute time, something
that is very beneficial, even for read-only virtual tables.
Dan.
