db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [jira] Commented: (DERBY-716) Re-enable VTIs
Date Thu, 19 Apr 2007 22:25:39 GMT
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 

> 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.


View raw message