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