Thanks, Dan. This is all useful feedback and will help make the next rev
of the spec clearer.
Regards,
-Rick
Daniel John Debrunner wrote:
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.
