[
https://issues.apache.org/jira/browse/DERBY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532693
]
Rick Hillegas commented on DERBY-3069:
--------------------------------------
Thanks again for helping me puzzle through this, Dan. Here are some responses
to your questions:
1) I like what you propose: if there is a non-varargs resolution for a routine
invocation, then that should be preferred over a varargs resolution. I think
that this means that we would keep two lists of candidate methods as we resolve
the invocation: JCS (already described in section 8.6) and JCVS (the set of
candidate resolutions which have vararg signatures). The extra varargs methods
which I proposed to put into JCS would instead go into JCVS. Then we would
continue:
a) If JCS has exactly one method in it, that is the resolution of the routine
invocation.
b) If JCS has more than one method in it, then we raise an error.
c) Otherwise JCS is empty and we continue:
d) If JCVS has exactly one method in it, then that is the resolution of the
routine invocation.
e) Otherwise, we raise an error.
Does this sound reasonable?
2) I think that INOUT and OUT parameters can resolve to varargs provided that
we are careful that the vararg type is itself an array. So, for instance if we
declare
create procedure foo( inout arg1 varchar( 30 ) ) ...
then an invocation of this procedure could resolve to the following method
public static void fooRes( String[]... inoutargs )
but not
public static void fooRes( String... args)
Right now, we are not correcty resolving these INOUT/OUT parameters against
varargs signatures. That is, we are not detecting the vararg candidates and so
resolution fails. That's a bug I need to fix. Are you seeing other subtleties
here?
3) I don't think I understand the subtleties of DYNAMIC RESULT SETS. Could you
elaborate on why you think that we should not support these as varargs? Off the
top of my head, it seems that we ought to be able to resolve dynamic result
sets to varargs. So for instance, if we declare the following procedure:
create procedure dynamicResultSet( arg1 int ) ... dynamic result sets 2 ...
then an invocation of this procedure should be resolvable to
public static void dynamicResultSetRes( int arg1, ResultSet[]...
dynamicResultSets )
4) I agree that it is unfortunate that we can't mix vararg parameters with
dynamic result sets.
> Derby does not resolve functions bound to methods with varargs.
> ---------------------------------------------------------------
>
> Key: DERBY-3069
> URL: https://issues.apache.org/jira/browse/DERBY-3069
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1,
> 10.2.1.6, 10.2.2.0, 10.3.1.4
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
> Attachments: derby-3069-01-varargs-aa.diff,
> derby-3069-01-varargs-ab.diff, z.java, z.sql
>
>
> Varargs were added in Java 5. It would be nice if Derby let you invoke a
> function bound to a method with a variable length argument list. The
> Reference Guide states a small number of restrictions for methods which can
> be invoked as Derby functions: They must be public, static, and not have
> arguments which are long datatypes. I see no reason that Derby shouldn't be
> able to resolve and invoke functions which are bound to methods which don't
> suffer these limitations but which have variable argument lists.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
