[
https://issues.apache.org/jira/browse/DERBY-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784566#action_12784566
]
Bryan Pendleton commented on DERBY-1030:
----------------------------------------
Thanks for the clear and detailed explanation, Rick, it was very interesting!
> JavaToSQLNode - This class is responsible for turning SQL data values into
> Java data values before
> they are passed as arguments to Java methods. So for instance, this class is
> responsible for compiling
> the runtime code which changes a SQLInteger into a primitive int before
> invoking a Java method.
>
> SQLToJavaNode - This class is responsible for the reverse operation, that is,
> for changing Java
> data values into SQL data values that can be used by other expressions in the
> query. So for instance,
> this class is responsible for compiling the code which changes Integer and
> primitive int into SQLInteger.
Did I misread this? It seems backward to me. It seems like JavaToSQLNode should
be the one which turns a Java value into a SQL value, and SQLToJavaNode should
be the one which
turns a SQL value into a Java value.
> In some situations a RETURNS NULL ON NULL function is called when one ot its
> parameters is NULL
> -----------------------------------------------------------------------------------------------
>
> Key: DERBY-1030
> URL: https://issues.apache.org/jira/browse/DERBY-1030
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.1.2.1
> Reporter: Daniel John Debrunner
> Assignee: Rick Hillegas
> Attachments: derby-1030-01-aa-disableOptimization.diff,
> derby479.java, derby479.sql
>
>
> The NULL argument to the function has to come from another function and that
> function's Java method has to return a Java object type corresponding to a
> fixed length SQL type, such as DATE, TIME and TIMESTAMP.
> Will attach repro scripts.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
