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 Tue, 18 Sep 2007 21:17:43 GMT

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


Mime
View raw message