Hi Rick,
There is a limited number of DatabaseMetaData methods have allowed this
to occur as part of the functionality. This was unfortunate IMHO.
-lance
Rick Hillegas wrote:
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.
