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 Fri, 05 Oct 2007 20:45:50 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532771
] 

Rick Hillegas commented on DERBY-3069:
--------------------------------------

Thanks for the continued discussion, Dan. Some more responses follow:

A) If we need another parameter style, I think that's ok. I would just like to keep the number
of parameter styles to a minimum.

B) To me there is a lot of value in taking advantage of Java 5 varargs even though you can't
declare vararg SQL signatures yet. I agree that it is awkward that your application code still
has to declare a separate SQL method for each new signature that it needs. Without support
for Java 5 varargs, the application has to do the following additional work too:

i) Generate and compile Java wrapper code for the new signature.

ii) Replace the relevant server jar file either directly on the classpath or as stored in
the database.

I find that eliminating these steps is a welcome benefit.


2) I can't say whether other people would find the INOUT/OUT resolution confusing. It seems
straightforward to me.


3) I haven't found a need for ResultSet varargs yet so I don't have any experience to suggest
whether this makes the code easier or harder to write. However, I think that the advantages
described for (B) still apply here. If we continue with the behavior described for (1), then
I think that the existing SQL Standard rules continue to apply.

Because I haven't personally needed ResultSet varargs yet, I don't have a lot of passion about
the issue. We could not support ResultSet varargs for 10.4. If someone needed this feature
later on, they could add it--by adding a third phase to the resolution process, we could continue
to preserve backward compatibility.

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


Mime
View raw message