db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-479) Passing the return of a RETURN NULL ON NULL INPUT function to another function call throws linkage error.
Date Tue, 21 Feb 2006 21:13:25 GMT
    [ http://issues.apache.org/jira/browse/DERBY-479?page=comments#action_12367261 ] 

Daniel John Debrunner commented on DERBY-479:

The comment you added/modified in MethodCallNode is:

+			** If the parameter is a SQL ValueNode, then put a
+			** SQLToJavaValueNode on top of it.

I see that as a comment that doesn't add any value, from the code I can see that is being
done, the real value in a comment is explaining *why* something is done.

Looking more at StaticMethodCallNode.optimizeDomainValueConversion() I'm not convinced it
is correct.
The comments and code seem to say if I have


then if f2() is CALLED ON NULL INPUT then I can take the java value directly from f2() and
pass it to f1().

But, what if f1() is RETURNS NULL ON NULL INPUT, don't I need the SQL nodes to perform the
NULL check?
Thus don't both methods, the one being called and the one providing the parameter have to
be CALLED ON NULL INPUT to take allow the conversion nodes to be dropped?

In the optimizeDomainValueConversion I think you need to check for the node being an instance
of StaticMethodCallNode and not MethodCallNode, and I think for routine being null. StaticMethodCallNode
and MethodCallNode are stil used for internal SQL that uses Java expressions directly and
are not defined SQL routines.

Another aspect that may not be important, but before this change the conversion nodes are
always dropped if they are between Java expressions, and that was incorrect in one situation,
functions with RETURNS NULL ON NULL INPUT. Now you have changed it so they are only dropped
in one situation, both methods being CALLED ON NULL INPUT (assuming a modified patch). Thus
the optimization is being lost in situations where it is useful. Maybe this is not an issue
because those siutations typically don't arise any more, but some internal statements that
use Java expressions may be losing this optimization.

> Passing the return of  a RETURN NULL ON NULL INPUT function to another function call
throws linkage error.
> ----------------------------------------------------------------------------------------------------------
>          Key: DERBY-479
>          URL: http://issues.apache.org/jira/browse/DERBY-479
>      Project: Derby
>         Type: Bug
>   Components: SQL
>     Versions:
>     Reporter: Daniel John Debrunner
>     Assignee: Mamta A. Satoor
>  Attachments: Derby479LinkageErrorReturnNullIfNulldiff021306.txt, Derby479LinkageErrorReturnNullIfNulldiff021406.txt,
Derby479LinkageErrorReturnNullIfNulldiff021606.txt, Derby479Version4LinkageErrorReturnNullIfNull022006.txt,
wisconsin.out, wisconsinAfterRemovingNullChk.out
> Error in ij (RN_RADIANS is a function declared as returns null on null input)
> ERROR XBCM1: Java linkage error thrown during load of generated class org.apache.derby.exe.ace5214067x0105x5e41x7a46xffff855452e375.
> ERROR XJ001: Java exception: '(class: org/apache/derby/exe/ace5214067x0105x5e41x
> 7a46xffff855452e375, method: e0 signature: ()Ljava/lang/Object;) Expecting to find double
on stack: java.lang.VerifyError'.
> extract from derby.log
> 2005-07-28 16:23:43.836 GMT Thread[main,5,main] Wrote class org.apache.derby.exe
> .ace5214067x0105x5e41x7a46xffff855452e375 to file C:\_work\svn_pb\trunk\systest\
> out\functions\ace5214067x0105x5e41x7a46xffff855452e375.class. Please provide sup
> port with the file and the following exception information: java.lang.VerifyErro
> r: (class: org/apache/derby/exe/ace5214067x0105x5e41x7a46xffff855452e375, method
> : e0 signature: ()Ljava/lang/Object;) Expecting to find double on stack
> I will add a test case to lang/functions.sql commented with this bug number. Test cases
> that fail will be commented out.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message