db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3069) Derby does not resolve functions bound to methods with varargs.
Date Fri, 05 Oct 2007 15:51:50 GMT

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


Mime
View raw message