Hi Lance,
Is it OK for a JDBC3 implementation to return more information than the
spec demands? In particular, consider the various result sets returned
by DatabaseMetaData calls. Is it OK for these result sets to contain
additional, trailing columns, above and beyond the columns required by
the JDBC3 spec? To be even more pedantic, can JDBC3 implementations
return the fatter JDBC4 result sets?
Thanks,
-Rick
Dyre Tjeldvoll (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-925?page=comments#action_12368699 ]
Dyre Tjeldvoll commented on DERBY-925:
--------------------------------------
I just realized that DatabaseMetaData.getProcedureColumns() has been changed in
JDBC 4.0. The result set it returns now conatains a number of new columns and
is, in fact, a super set of the columns returned by getFunctionParameters. For
JDBC 4.0 it will likely be necessary to extend the existing
GetProcedureColumns.java VTI with much of the same information that I was
thinking about putting into the new VTI. Perhaps both methods can be
implemented with queries against a single VTI? We will probably need a separate
getProcedureColumns40 query in metadata.properties to maintain backward
compatibility?
Implement new JDBC 4 metadata API getFunctionParameters()
---------------------------------------------------------
Key: DERBY-925
URL: http://issues.apache.org/jira/browse/DERBY-925
Project: Derby
Type: New Feature
Components: JDBC
Versions: 10.2.0.0
Environment: JDK 1.6
Reporter: David Van Couvering
Assignee: Dyre Tjeldvoll
Attachments: TypePrinter.java
I am currently implementing this to return an empty result set so at least
we're compliant, but we should be able to provide real metadata here.
