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.