From derby-dev-return-49329-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Fri Oct 05 15:52:13 2007 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 48805 invoked from network); 5 Oct 2007 15:52:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Oct 2007 15:52:12 -0000 Received: (qmail 49820 invoked by uid 500); 5 Oct 2007 15:52:00 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 49792 invoked by uid 500); 5 Oct 2007 15:52:00 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 49783 invoked by uid 99); 5 Oct 2007 15:52:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Oct 2007 08:52:00 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Oct 2007 15:52:10 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id A0E5A71422B for ; Fri, 5 Oct 2007 08:51:50 -0700 (PDT) Message-ID: <2325784.1191599510647.JavaMail.jira@brutus> Date: Fri, 5 Oct 2007 08:51:50 -0700 (PDT) From: "Rick Hillegas (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-3069) Derby does not resolve functions bound to methods with varargs. In-Reply-To: <6425104.1189562012317.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532693 ] Rick Hillegas commented on DERBY-3069: -------------------------------------- Thanks again for helping me puzzle through this, Dan. Here are some responses to your questions: 1) I like what you propose: if there is a non-varargs resolution for a routine invocation, then that should be preferred over a varargs resolution. I think that this means that we would keep two lists of candidate methods as we resolve the invocation: JCS (already described in section 8.6) and JCVS (the set of candidate resolutions which have vararg signatures). The extra varargs methods which I proposed to put into JCS would instead go into JCVS. Then we would continue: a) If JCS has exactly one method in it, that is the resolution of the routine invocation. b) If JCS has more than one method in it, then we raise an error. c) Otherwise JCS is empty and we continue: d) If JCVS has exactly one method in it, then that is the resolution of the routine invocation. e) Otherwise, we raise an error. Does this sound reasonable? 2) I think that INOUT and OUT parameters can resolve to varargs provided that we are careful that the vararg type is itself an array. So, for instance if we declare create procedure foo( inout arg1 varchar( 30 ) ) ... then an invocation of this procedure could resolve to the following method public static void fooRes( String[]... inoutargs ) but not public static void fooRes( String... args) Right now, we are not correcty resolving these INOUT/OUT parameters against varargs signatures. That is, we are not detecting the vararg candidates and so resolution fails. That's a bug I need to fix. Are you seeing other subtleties here? 3) I don't think I understand the subtleties of DYNAMIC RESULT SETS. Could you elaborate on why you think that we should not support these as varargs? Off the top of my head, it seems that we ought to be able to resolve dynamic result sets to varargs. So for instance, if we declare the following procedure: create procedure dynamicResultSet( arg1 int ) ... dynamic result sets 2 ... then an invocation of this procedure should be resolvable to public static void dynamicResultSetRes( int arg1, ResultSet[]... dynamicResultSets ) 4) I agree that it is unfortunate that we can't mix vararg parameters with dynamic result sets. > 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, derby-3069-01-varargs-ab.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.