[
https://issues.apache.org/jira/browse/DERBY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485096#comment-13485096
]
Rick Hillegas edited comment on DERBY-3069 at 10/26/12 6:54 PM:
----------------------------------------------------------------
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 0.
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 derby 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?
Thanks,
-Rick
was (Author: rhillegas):
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 0.
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?
Thanks,
-Rick
> 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
> 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
