[
https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493517
]
Daniel John Debrunner commented on DERBY-716:
---------------------------------------------
Still not sure "Java type" is correct. Is that really the rule for deciding if
the arguments can be mapped to the parameter type?
For regular (non-table) functions and procedures the check is made to see if
type of the SQL argument can be stored in the
type of the SQL parameter (defined in the routine's CREATE statement). Maybe
checking the java types would lead to the
same answer, but logically it's a check of SQL types only.
Table functions should follow the same logic as regular functions.
See this check in StaticMethodCallNode.java
if (!
getTypeCompiler(parameterTypeId).storable(argumentTypeId, getClassFactory()))
throw
StandardException.newException(SQLState.LANG_NOT_STORABLE,
parameterTypeId.getSQLTypeName(),
argumentTypeId.getSQLTypeName() );
> Re-enable VTIs
> --------------
>
> Key: DERBY-716
> URL: https://issues.apache.org/jira/browse/DERBY-716
> Project: Derby
> Issue Type: New Feature
> Components: SQL
> Reporter: Rick Hillegas
> Attachments: functionTables.html, functionTables.html
>
>
> Cloudscape used to expose Virtual Table Interfaces, by which any class which
> implemented ResultSet could be included in a query's FROM list. Derby still
> exposes a number of these VTIs as diagnostic tools. However, Derby now
> prevents customers from declaring their own VTIs. The parser raises an error
> if a VTI's package isn't one of the Derby diagnostic packages.
> This is a very powerful feature which customers can use to solve many
> problems. We should discuss the reasons that it was disabled and come up with
> a plan for putting this power back into our customers' hands.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
