[ http://issues.apache.org/jira/browse/DERBY-479?page=comments#action_12365609 ]
Daniel John Debrunner commented on DERBY-479: --------------------------------------------- It helps in these situations to be clear about SQL function vs. Java method. For example the the first sentence in the last comment should be: > The function is defined such that if the argument to it is null, it should > simply return null w/o invoking the method. Then this leads to the next sentence saying: > But, in order to return null, the method's return type can't be primitive This is wrong, if it relates to the first sentence, if the method is never being called when the input is SQL NULL, then it doesn't matter what the return type of the method is (since the method is never called). It is correct however if the method needs to return a NULL value when the input parameters are not NULL, or the SQL function is declared as CALLED ON NULL INPUT. then the Java method does need to have a return type of java.lang.Integer. One thought is related to the handling of converting types between the SQL domain and the Java domain. The nodes pushed for such an expression are something like: JavaToSQL( StaticMethodCall( SQLtoJava ( JavaToSQL ( StaticMethodCall (constant 90) ) ) ) ) That is any compiled node that results in a Java value is automatically wrapped in a JavaToSQL node that converts the value from the Java space (a Java object ot primitive) to the SQL space (a DataValueDescriptor). The assumption is the Java value is most likely returned to the SQL space. If a SQL value needs to be pushed into the Java space the converse node is used. When a SQLtoJava wraps a JavaToSQL node (or vice versa) the compiler (I think) will just remove these two nodes so that there is no performance overhead due to the no-op conversion . I think the logic for this removal was not updated for the RETURNS NULL ON NULL INPUT case, because this clause means the double conversion is not no-op. > 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 > > 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
