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, 26 Oct 2012 18:29:12 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485096#comment-13485096

Rick Hillegas commented on DERBY-3069:

Here is my current thinking on this topic:

1) We would clearly mark this as a Derby extension by using a new DERBY parameter style.

2) We would clearly mark routines which were meant to resolve against vararg methods. If the
last (and only the last) argument of the routine declaration ended with an ellipsis token
(...), then the routine would have to resolve to a Java varargs method.

So, for example, consider the following SQL function definition. Note the use of the DERBY
parameter style and the ellipsis token:

create function maximum( a int... ) returns int
language java parameter style derby no sql
external name 'IntFunctions.maximum';

This SQL signature would resolve to the following Java vararg method:

    public  static  Integer maximum( Integer... args )
        if ( args == null ) { return null; }
        if ( args.length == 0 ) { return null; }

        int     result = Integer.MIN_VALUE;
        for ( Integer value : args )
            if ( value == null ) { return null; }
            else { result = Math.max( result, value.intValue() ); }

        return result;

3) We would need to decide what to do about procedures which return dynamic ResultSets. That
is because dynamic ResultSets and Java varargs both make claims on the trailing arguments
of the Java method signature. Here are some possible ways to handle this problem:

3a) Do not allow varargs if the procedure is defined with a DYNAMIC RESULT SETS greater than

3b) Allow the Java varargs argument to come AFTER the ResultSet[] arguments. So the Java method
signature would begin with the non-vararg arguments, followed by a number of ResultSet[] arguments
equal to the value of DYNAMIC RESULT SETS, followed by a trailing ellipsis tagged argument.
So this SQL declaration

create procedure varargProcWithDynamicResultSets
( in a int, b int, in f bigint... )
language java parameter style java reads sql data
dynamic result sets 2
external name 'Procs.varargProcWithDynamicResultSets';

would bind to this Java signature:

public static void varargProcWithDynamicResultSets
( int a, int b, int c, ResultSet[] d, ResultSet[] e, long... f )

What do other people think?

> 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:,,,,,,,
>            Reporter: Rick Hillegas
>              Labels: derby_triage10_10
>         Attachments: derby-3069-01-varargs-aa.diff, derby-3069-01-varargs-ab.diff, derby-3069-02-backout.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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message