[
https://issues.apache.org/jira/browse/DERBY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528566
]
Rick Hillegas commented on DERBY-3069:
--------------------------------------
Dan posted the following questions on derby-dev because JIRA was down:
>Is there going to be some write up on exactly how the proposed method
>resolution will work with varargs, so that people can review it and see if it
>conflicts with the standard method resolution?
The current resolution rules are mentioned in the Reference Guide section on
CREATE FUNCTION in the subsection on PARAMETER STYLE. There the reader is told
that the resolution rules are the ones described in part 13 of the SQL
Standard. Let us call those resolution rules the OldRules.
1) If the Derby engine is running on a pre-Java-5 vm (that is, JDK 1.4 or the
CDC small device platform), then the resolution rules are the OldRules.
2) If the Derby engine is running on Java 5 or later, then the resolution
rules are the OldRules with the following change: The SQL Standard, part 13,
section 8.6, refers to the resolution rules described in The Java Language
Specification, Second Edition. Replace that with a reference to the resolution
rules in The Java Language Specification, Third Edition.
>Will this be a different PARAMETER STYLE (than JAVA)? If not what does it say
>about Derby's commitment to standards when a SQL routine resolves to a method
>in Derby that it would not resolve to on another database that is following
>the SQL standard?
I would have no problem limiting the application of these rules to
functions/procedures which are declared with some other PARAMETER STYLE.
Currently, we have 2 parameter styles, namely, JAVA and DERBY_JDBC_RESULT_SET.
The second style is used for Derby-style table functions as described in
DERBY-716. You are only allowed to specify one parameter style according to the
SQL Standard, part 2, section 11.50, syntax rule 6a. Now we need to consider
the problem of ORing parameter styles together, so that, for instance, we can
have a table function resolve against a method with a varags signature. I see a
couple solutions to this problem:
a) Introduce one new parameter style. Let's call it DERBY. Get rid of
DERBY_JDBC_RESULT_SET. If the parameter style is DERBY, then table functions
resolve to ResultSet-returning-methods and vararg resolution happens according
to rule (2) above. In this scheme, there are 2 parameter styles: JAVA and DERBY.
b) Introduce one new parameter style. Let's call it DERBY_VARARGS. The existing
DERBY_JDBC_RESULT_SET parameter style continues to behave as it does today,
that is, it resolves table functions to ResultSet-returning-methods but it uses
OldRules regardless of the platform. Parameter style DERBY_VARARGS behaves as
parameter style DERBY does in case (a). In this scheme, there are 3 parameter
styles: JAVA, DERBY_VARARGS, and DERBY_JDBC_RESULT_SET.
c) Introduce two new parameter styles. Let's call them DERBY_VARARGS_PLAIN and
DERBY_VARARGS_JDBC_RESULT_SET. DERBY_VARARGS_PLAIN follows vararg resolution
rule (2) but does not resolve table functions to ResultSet-returning-methods.
DERBY_VARARGS_JDBC_RESULT_SET behaves as parameter style DERBY does in case
(a). In this scheme, there are 4 parameter styles: JAVA, DERBY_JDBC_RESULT_SET,
DERBY_VARARGS_PLAIN, and DERBY_VARARGS_JDBC_RESULT_SET.
I would vote for option (a). As time goes on, people may need to implement
other Derby-specific method resolution rules. At that time, they should
consider whether to enrich the DERBY style or create a new one.
> 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, 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.
