[ 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 f1(f2()) 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: 10.2.0.0 > 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) > ij> VALUES CAST( CALL_COS(RN_RADIANS(90.0)) AS DECIMAL(3,2)); > 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
